Notes about full stack Javascript software development

Menu

Backbone or Angular or Ember? Here is my choice and why

I’ve spent the last year neck deep in the main MVC / MV* whatever frameworks for Javascript. It was a very hard choice to pick a favorite and stick with it. I started out with Backbone, moved on to Angular and finally settled on Ember. This convoluted process is the reason I haven’t blogged in a few months, I really had to pick what client-side framework to blog about. This is my reasoning:

Backbone is great, minimal and not opinionated which I like, as such it resembles classic Javascript the most and has the least steep learning curve, but the main point against it – that you need a lot of boiler plate code to make it work well – is valid. This means that you have to do the architecture and wiring yourself and can cause a giant mess which is not much better than spaghetti code jQuery really, or to avoid that you either have to reinvent the wheel to set up your project or bring boilerplates into your projects every time. You also have the option of bringing in extensions like Marionette and Layout manager, but at that point it’s not so minimal and becomes opinionated which kind of beats the purpose of using Backbone in the first place. Besides that, Backbone is starting to feel old and lacking features compared to the newer frameworks. I also dislike the way Backbone doesn’t have actual controllers, it has views and templates, there is no clear separation between the business logic which in my mind belongs in a controller, and UI interactions which do not. This makes it easy to end up with an app which doesn’t allow easy iteration through UI variants.

Angular is really impressive at first glance, it can do quite a lot of amazing stuff, like 2-way bindings, helpful out of the box directives and filters. Angular also has quite nice support for module dependencies and injections, it has services and factories which become reusable parts for your app. It also enforces quite strongly separation between logic and presentation which allows you to make UI presentation variants quickly while the underlying logic remains the same. In my opinion Angular is the closest thing to a real software engineering solution for front-end web development, in some ways it resembles Java, in some ways .NET. That all sounds great, why did I not stick with it? It is mostly personal preference, but I dislike how extremely opinionated Angular is and how much it deviates from classic Javascript UI development. Unless you do everything according to the “Angular way” you end up confused and fighting the framework instead of gaining benefit from using it. Directives which are super complicated and odd are a true embodiment of this, but in Angular almost everything is done differently. This means that prior experience in creating UI with Javascript is rendered almost useless. No matter who you are, you have a very steep learning curve and along the way you really start questioning the benefit. At times I do feel enabled by Angular’s different paradigm, but far too often I find myself frustrated. The framework is loaded with syntaxes, concepts, keywords, patterns that exist nowhere, but in the Angular framework and memorizing and gaining this skill doesn’t make you a better overall software engineer or Javascript coder, it makes you better in Angular. It reminds me a lot of the .NET framework in that way which I ultimately also decided is not worth it.

Ironically I’m by far least experienced in Ember, but I like it the most already (I’m hoping that doesn’t change and I end up having to learn yet another MVC framework). Ember can do almost all that Angular can and equally fast or faster, and it manages to achieve that without deviating so much from classic Javascript syntaxes and patterns. It looks quite a lot like Backbone, but where Backbone is either loose or lacking features, Ember has it covered and enforces best practice. It is closely tied to the Handlebars templating engine which I believe is the most superior and is also used by 2 other Javascript tools which I love using – Ghost and Assemble. This means that whether making static sites, CMS, blog or single page application with MVC, or combining all of those, you can re-use your templates and helpers from Handlebars, you can also bring in anyone’s pre-made directives and helpers and gain a very big toolset. Unlike in Angular, in Ember you can use any of jQuery’s powerful features which we all know and love (we Javascript devs that is). You can transfer almost all your prior skill and knowledge to Ember development. Ember feels to me like Backbone on steroids – it has a similar feel, but is a lot more powerful and structured. I also like that it has standardized its templating and patterns, this way unlike with Backbone, you can borrow from any pre-existing Ember app or example.

For these reasons I chose Ember.js and am excited to be able to focus and devote my further writing in this blog to it.

Update: People have been asking how I like Ember since I decided to focus on it. I love it and I’m absolutely certain I made the right choice. I now work full time making apps with Ember and have just released my first open-source project – a full Javascript stack with Ember as a client and Node API as a server. Download here – https://github.com/mgenev/Full-Stack-JS-Amber.

40 thoughts on “Backbone or Angular or Ember? Here is my choice and why”

Manos Ragiadakos

Sebastian

December 27, 2013 at 10:18am

Thanks for the post. After doing several projects with Backbone and Angular, I always end up going back to CanJS, I find it to be the one with the best balance. But I haven’t use Ember for anything big yet.

Erikas

keuller

December 28, 2013 at 8:33pm

hi, did you tryied to use Backbone with Marionette extension? In my opinion Marionette brings to Backbone a powerful architecture features and makes Backbone more simple, reducing boilerplate code and increasing productivity to single page application development.

Tony

I fully agree with your choice.
Two years ago I was developing SPA using Backbone and I had to implement sort of app skeleton. Four months ago I’ve started working on new SPA based on Ember.js, which fixed these Backbone, let’s say, shortages. In result, two junior developers appreciated this choice and easily dived into development with Ember.js

Akaryatrh

December 29, 2013 at 11:25pm

Looks a bit weird to choose a JS framework mostly for its templating engine. Anyway, from my side, i feel confortable with ChaplinJS (made on top of backbone), and handlebars for templating. Everything is compiled, processed and minimized thx to Brunch.

Oleksii

January 6, 2014 at 5:51pm

Your are not able to choose framework for all your needs in all project. I made a big investigation of different frameworks during last 5 months and I can tell you that no one have recipe for all challenges or when you start to work with 10000+ elements

olivvv

January 13, 2014 at 1:28pm

ahah I faced that too, 9000 elements, IE7 and sizzle crawling all that by hand.
There is a bunch of tools to handle that :
– show/hide to memory instad of css display none
– Event Delegation
– No $ node selection without context node

but that all stuff I never see mentionned in ppl talsk about perfs ans SPAs.

Michael Christenson II

January 8, 2014 at 1:59am

I get you. I was torn between Emberjs and Angularjs for my latest project; coming from a Rails career for the past decade MVC is drilled into my head. In the end it was too much trouble hiring people who knew Emberjs for a quick ramp up. I compromised by hiring people who knew at least a little Angularjs and, as the lead developer, I set a MVC convention for developers to follow.

I’m enforcing this through code reviews and paired programming rather than actual framework constraints. So far I think it works fine. Framework opinions are great and all, but I often wonder why we need them. Often consensus between coders can form a working convention while giving enough flexibility for all.

Also, regarding Angularjs strictures, it’s easy to make a factory that pulls in jquery or any other library in for use in the whole app. I use a one liner to pull underscore in and use it as normal. Consider it like using requirejs. It’s just a configuration setting.

Rafael Rocha

February 4, 2014 at 2:16pm

Great post dude but I missed unit testing on it. I’m not so experienced on these MV* frameworks but I’ve been in touch mainly with Backbone and Angular and what I’ve seen is that only Angular and Knockout is based on composition. Ember and Backbone are based on extension what makes unit testing a little bit tougher and obscure, since you have to mock/spie/double behaviors of your parent object which is under test. Have you tried coding unit testing on each of them? Do you have any insight of?

Steve T.

February 5, 2014 at 8:40pm

I can’t agree with you OP that slogging through Angular’s concepts and paradigms is not going to make you a better programmer. Any time you’re wrapping your mind around the unfamiliar you are learning things that you are going to take back to your own programming.

That said Angular does have a really steep learning curve that most teams just don’t have time to invest in.

Bogdan Kulbida

Imho, you can’t go past Angular for sheer power and scale. It takes a novel, fresh look at the client (rather than just porting server concepts to the browser), allows you to build libraries that are easily shared amongst the community (your point on ember directives as though it’s exclusive is simply incorrect), and, I have to say – after working with it for 2 years, has never gotten in our way.

It certainly does have a learning curve, though – and directives are are a supremely complex beast. Once you have it down though, I simply can’t go back to Ember, or Backbone, or any of the others. Angular JS is imho, much faster (to develop with), and far more powerful (if you think ember is backbone on steroids, then Angular JS is simply SSJ – god mode :P).

The worst part of Angular, is the learning aspect. But you can’t just take what you think of mvc and apply it to angular. Once you know how IT manages MVC, then it becomes clearer. Also – why would you want all of jQuery’s tools? It’s a slow, dated beast that mostly works on the DOM rather than any form of binding and scopes that makes angular so damn powerful.

Mark Cooke

March 4, 2014 at 5:14am

I looked at Knockout, Backbone, Ember, and finally Angular. In the end, I chose Angular because it used concepts familiar with both .NET WebForms and MVC developers, and because it was the only framework of all 4 that uses POJO model objects that don’t require any JS initialization code or remembering to call a setter method. In addition, directives are a clean declarative way to pass server logic to the client via HTML markup.
But these were clearly advantages in a non-SPA environment where the client code has to exist with a lot of legacy server-side markup. In a greenfield project, I might easily choose another framework.

So, howz it going with Ember ? Do you regret your decision of moving from Angular to Ember ?
I doubt Ember has same community strength as Angular. Have you evaluated any other options ? Did ember was the one finally you ended up using the most ? A quick updated article about your experience with Ember would be great.

Nikos

sanjay

May 2, 2014 at 3:25pm

Hi. I m new to web. Instead of any comments I need this community support to sort out the confusion. We r working on a social network plate form (same as Facebook but with different intension ). Which MVC choice i need to opt given that:
1) we all r new in the web
2) all are almost fresher apart from one that too he is completely new in web
Please suggest .

Alejandro

May 21, 2014 at 3:45pm

Hi, which framework recommend to create a very interactive app like Trello.com (drag & drop, forms with fields becoming editable when double clicking them, divs moving around the screen or changing size and colors when I do :hover in any other div,etc.). What I need is the best framework to create an awesome User Interface and User Experience. Maybe I’ll need to code lot of CSS3 as well.
I’m a Ruby on Rails dev, do I need a server side application in Rails or all is done in the client? The project also needs a big database behind.

Nick den Engelsman

Tusshar

Mihai

June 19, 2014 at 10:36am

Well, Angular JS community is getting larger and larger, Durandal creator joined the Angular team. Why is that?
Angular provides you with a clean way of separating your view from the model, it is MVC.
And yes AngularJS doesn`t need Jquery, Jquery was wrong in the first place,
– has support for tests, and testing is fairly simple
– extends the doom. Doesn`t fight against it.
– you can create reusable components with directives.
I`ve chosen angular after trying ember,durandal,knockout, and in my opinion all looks very natural.

mgenev@gmail.com

June 19, 2014 at 3:28pm

Ember can do all these things you mentioned, except extending the doom, that would be pretty scary, but Angular does do it indeed. In the end of the day whatever feels better to you should be your choice

borg

Perambulator

December 29, 2014 at 3:18pm

Actually, since this post was written, the Durandal creator, Rob Eisenberg, left the Angular project, as he disagreed with the direction that version 2.x is taking, and has refocused his efforts on Durandal.

Angular has many benefits, but it is far from the only framework that offers them. Much of its success has been due to marketing effort that Google has put in to it, but once details of the breaking changes in version 2.x became known, many developers are taking a second look at the alternatives.

David Spenard

September 8, 2014 at 6:47pm

My, my, what a confusing mess client-side development has become. That’s mostly a tongue-in-cheek statement because it seems like only yesterday I was doing plain old Javascript (and even VBScript long ago), then thought the web world would be saved by JQuery, only to realize that JQuery just produced tighter spaghetti code because of the lack of structured Javascript and just plain old poor coding techniques by far too many inexperienced, undisciplined developers. Nonetheless, client-side libraries and frameworks have and will always be sorely needed, which is why I’ve looked at Knockout, Backbone, and Angular, and I’m now looking at Ember. After reading this blog and a few others, I’m still not convinced what direction to go, but at this point it doesn’t really matter because they are all far superior than plain old Javascript or JQuery. I do like Angular more than Knockout and Backbone, for various reasons already mentioned, but we’re going with Ember for new development efforts on the job because I’m finding more and more proponents for it and it’s also in use in another development group where I work. Could it be the wrong choice over Angular? Only time will tell. But the point is that if you develop a repeatable pattern and framework around your software development efforts, where you increase productivity and produce scaleable, maintainable, extensible solutions, then you’ll probably be fine regardless what Javascript library or frameowrk you use. I’m quite exhausted from trying to figure out if Angular or Ember is the way to go, so I’m looking forward to actually using Ember to get some work done and stop dying from Javascript library analysis paralysis.

Nilesh

December 18, 2014 at 10:38am

Thanks for post….
I am familiar with Ember.js than any other frameworks mentioned above.And i am finding it comfortable to use.Which framework do you recommend to create a very interactive app like Groupon,ebay,Amazon?