1 August 2014
Give your Backbone.js apps super-powers with AngularJS style directives


Backbone Directives is a new open source project that improves Backbone.js by adding directives support. Demo here and source at GitHub.

Some Backbone History

I’ve been using Backbone for the past two years or so. I loved it from the very first time I’ve used it. Finally there was a good and simple way to structure web apps. From small side projects to large production real-time applications.

I invested a lot to inspect its source code, to understand how everything really works. I’ve written a few blog posts about it.

All the web stuff I wrote in the past 2 years has been based around Backbone, even on the server side.

Secret: AngularJS scares me

Well, it did. I used to hear people talk about the new hotness and I didn’t really want to let go of Backbone. I took quick looks from time to time and found some stuff I didn’t like in AngularJS:

  • The DOM was filled with things like “ng-click” which reminded me of the spaghetti age of HTML and Javascript.
  • There were a lot of TODO lists examples, but nothing bigger.
  • Too much “magic” is happening without me needing to understand it.
  • It had no way to render on the server side.

The only way I knew to get into this is to create a small project and learn. I created Hinder with AngularJS and was amazed at how easy it was to write it. Much more concise than my Backbone apps.

This was a nice intro into the AngularJS world, but it wasn’t enough. I feel like I only scratched the surface of it. On top of that, I felt there was too much magic happening in the background. I really don’t like that filling of not understand how things actually work.

I found the following amazing blog post titled Make Your Own AngularJS. It explains step by step how AngularJS works and you really should read it.

So now I’m not afraid of AngularJS anymore.

The one thing I really liked is Angular’s directives. The fact you can use expressions for model-view bindings (as in: price.total - vip.discount) just blew me away.

I’ll describe directives as additions to the HTML syntax that allows the browser to do more than it was programmed to. This makes life easier for us developers.

Dropping Backbone and switching to AngularJS?

No, Not Yet. Maybe in future projects, but at this point converting the entire Backbone.js code base isn’t ROI positive.

Doing so will take too much time, effort and introduce new bugs to the system.

Making Backbone apps better

Backbone.js is easily extendable. We’ve seen it happen with the likes of Backbone.Relational, Backbone.Validation and other small but important improvements over the basic Backbone library.

Existing Backbone.js code bases can benefit a lot by adding more power to Backbone itself. I think directives will be a good addition and I’ve set to do it.

Backbone Directives

As a developer I always want to see something working before I get into the finer details, so here is a Demo you can checkout.

This is currently a proof of concept, but it works quite nicely. It’s not optimized for performance, it lacks testing and has a very small number of implemented directives.

AngularJS directives has the prefix of “ng-“, so for Backbone directives I thought “bb-” would fit nicely.

The basic idea is this:

1. There’s a Backbone.Model with an attribute. Let’s say the attribute is counter:

2. There’s a view that has a DOM element (it either takes control of an element, or creates one itself). The only thing needed to add for Backbone Directives is a call to this.$compile() in the render method:

3. Add directives to your DOM, we will add the bb-bind directive:

This will make sure the text of this span always shows the correct “counter” value of the model and track its changes.

4. We can also use an expression instead of a plain attribute. Here are two examples:

That’s all there is to it.

This is only one directive and anyone can add new directives. It should be pretty simple and straightforward.

At this initial release, there are 3 directives: bb-bind, bb-show and bb-class.

Take a look at the source code. It uses Angular’s parser for expressions, but other than that the code can fit on your screen (if you have a big one). I’m trying to make sure the code stays simple.

To Do

There’s a lot I’d want to see in the future:

  • Add missing directives
  • Match directive syntax with those of AngularJS, to eliminate the need for documentation.
  • Performance testing and tuning
  • Server side support with node.js

Final thoughts

From an outsider look, Backbone still feels more structured than AngularJS. However, the wind is blowing in Angular’s direction and I’m starting to see why.

I hope this project can inject some powers into Backbone. If it is going to be more than a proof of concept, I won’t be able to do it all by myself.

I’d really love to hear what you think of this. Is this something you’d like to use in your own projects? Do you have any suggestions? Would you like to help?

I’d love to talk about this over at Twitter: @ketacode

30 July 2014
Why English???

My wife asked me the other day:

"Why are all your emails written in English?"

I had the pleasure of working for Israeli startups as well as for more established Israeli high-tech companies.

In both of these organizations, the only language written in emails is one: English.

For 99% of the employees, English is not their mother tongue. As you can probably guess from reading my blog - it isn’t mine as well.

We speak, think and dream in Hebrew. We express ourselves best in Hebrew. We read faster in Hebrew. We understand Hebrew better. We have a bigger vocabulary. Hebrew is everywhere.

Except for emails. They are still written in English. Even when one team mate emails another - they both speak native Hebrew, but their email exchanges will be written in English. Weird, right!?

Why English?

If the emails are less effective in English, why is this the prefered language for Israeli companies? Here’s my ideas:

  • Vocabulary. The startup/computers/technical world has its own vocabulary. Not every word has a match in Hebrew. It’s more clear for us to use the original word instead (Examples: “Startup”, “MVP”, “Commit”, “Java”, “Compile”, “Protected Field”).
  • Technical issues. Mixing Hebrew and English in a single sentence is painful. Hebrew is written from right-to-left and English is written the opposite: left-to-right. Combining both causes a lot of unwanted errors in emails and even the cursor gets confused sometimes.
  • Sharing. Some emails might be forwarded later to an English speaker. Instead of translating the entire thread at that point, we keep the emails in English.
  • Practice. I think a lot of employees just uses it as a way to practice their English.

I too use English for almost all my emails. There are a few emails I do write in Hebrew.

When “to Hebrew”?

  • Important. The side effect of all this is that Hebrew emails stand out. So whenever I want to get people’s attention - I use Hebrew.
  • Clarity. I’m more clear and people understand my messages better when I write in Hebrew.
  • Non work. If I know my emails will never be forwarded to a non-Hebrew speaker, I might write in Hebrew.

Is this only an Israeli thing?

21 July 2014
How to be an awesome software engineer

These are the most important things I value in software engineers.

These are the traits of the people I want to be working with.

Complete the task to its fullest. At the end of the task, you should be able to announce: “It’s done, it’s great and I’m proud of it.”.

Be in ❤ with anything Simple. Prefer the simple solution over the smart/shiny/brilliant solution. Create things that needs the least explanation/documentation/illustration.

Over communicate with me, other team members and anyone in general. Let us know what you’re doing and how. Share your progress. Share your thoughts & insights. Be open to questions.

Adopt a “We can do it attitude”. Strive to be the best, produce the better product and help your team mates and company win.

5 June 2014
Notes from coding in Swift

I had to find out what Swift is all about so I thought using real production code will be a good idea.

I’ve taken the short task of porting the Sequencer code from Objective-C to Swift (result is here).

The Sequencer Obj-C code uses blocks extensively so the resulting Swift code revolves around closures.

It wasn’t a swift to do, but here are some stuff I learned along the way:

I suggest opening up the resulting file Sequencer.swift and the Objective-C source Sequencer.h and Sequencer.m

Defining Closures

I started by converting the blocks definitions to closure definitions.

Objective-C uses typedef for that:

typedef void(^SequencerNext)(id result);
typedef void(^SequencerStep)(id result, SequencerNext next);

In swift, this can be done with typealias:

typealias SequencerNext = (AnyObject? -> Void)
typealias SequencerStep = (AnyObject?, SequencerNext) -> Void

There’s a lot to see here, but focus on the, but the code pretty much speaks for itself. Except for the question mark, but we’ll get to that soon.

Void is still okay

As you can see from the code above, closures can be defined to return no value.

(Int, String) -> Void


I was looking for the equivalent of id and was tempted to use NSObject. Finally I found that the answer is AnyObject.

The only difference you can’t set it to nil. Take a look at Optionals for an answer.


Optionals offer a variable with either a typed value or no value at all.

This is done by a question mark:

var str: String?

You can resolve the optional by using the ! sign:


When str is nil, it will throw an exception.

Declaring arrays

Next up was declaring the array of steps. The Obj-C way is:

NSMutableArray *steps;

Notice that it’s mutable and can store any kind of object. Now the Swift code goes directly into the class definition:

var steps: SequencerStep[] = []

This is also mutable, noted by the var keyword. It’s now typed to only accept SequencerStep closures. It’s also already initialized to an empty array.


From that point, it was simply a matter of directly porting the Sequencer’s methods from Obj-C to Swift.

It’s all straight forward, but two things can be noticed here:

1. Operator overloading

Didn’t we agree this was a bad practice? What does the following line do?

steps += step

Answer: the same as the next line:


I personally prefer the second.

2. Inferring Types

Again, powerful closures can be written with very little characters in them. Take a look at this:

step(result, { result: AnyObject? in return self.runNextStepWithResult(result) })

vs. this:

step(result, { self.runNextStepWithResult($0) })

They both do the same thing. The $0 knows its type and the compiler is happy.

The syntax might only be understood by the writer of the code. It seems this is the recommended way.


After getting used to the new syntax and new concepts it all went smoothly.

Finally there is no need for an header file. This cuts done almost 1/4 of the code.

The code is also notably shorter, but this comes at the cost of readability.

Will this kill Objective-C? We’ll have to wait and see.

Let’s talk more on Twitter (@ketacode)

10 May 2014
The secret for creating amazing products

I’m gonna share the secret for creating awesome products your users will love.

I’ll get to that in a bit, but before that I’m going to share my experience from today’s soccer session with my friends.

We met at the regular court and divided all the players into two teams. For some reason, the person who chose my team had no idea who plays well and who sucks. The other team had great players and the people on my team were about to raise a white flag before we even started playing.

The game started and to everyone’s surprise we found out we were playing so much better than the other team. Well, we won 5:0. Underdogs can win, who knew?

How could that be? They had the better players. What I’ve noticed is that this knowledge drove each one of us to give his best to the team.

We cared more. When someone lost the ball, he ran as fast as he could to defend. When someone passed the ball to the wrong side, he cared and tried to get it back. The strikers knew we won’t have a lot of chances so they scored each one they had.

We weren’t making a product, but we did produce something: a win.

So what’s the secret? You probably know it by now. The secret is to care more.

Care more to make the user experience amazing.

Care more about what your users feel.

Care more for your new users.

Care more for your existing users.

Care more when the pixels aren’t aligned.

Care more about the texts your users see.

Care more when a team member needs help.

Care more before your user is a user.

Care more after a user leaves.

Care more and win.