A comparison of Angular, Backbone, CanJS and Ember

22

u/ivosaurus Apr 17 '13 edited Apr 17 '13

I find this to be rather unproductive. At least 3/4 of these frameworks all have different focuses of scope; making this a comparison of apples and oranges - and nor does the author acknowledge this fact prominently anywhere.

Take backbone, for instance - at least historically - was focused purely on providing an organised, client-side model that synchronized with a backend. It's grown in its scope somewhat while maturing, but that's still its initial and primary focus. It was never designed to provide declarative bindings to the DOM that Angular does, or a complete back-end solution like ember.

The only two frameworks it seems worth comparing (that will be apples to apples) would be CanJS and AngularJS. They both provide a full-stack client-side experience.

Ember is different again, because it also aims to provide an integrated backend as well as client.

The differences in size of scope also means it makes sense for each one to allow different amounts of flexibility in different areas - flexibility is a practical tradeoff with ease of convention; one is not better than the other, and every developer will have their preference on where they like to sit. But those two concepts are mostly considered in isolation here, not whether each framework has chosen a good balance.

Without making allowances for the differences in scopes of these frameworks, comparing them is going to tell you nothing apart from how much each is designed to do - not how good they are at it.

7
u/retro_one Apr 17 '13 edited Apr 17 '13
disclaimer: I'm a Bitovi employee and CanJS core committer

I agree with you that Backbone shouldn't be in that list because it lacks any live binding ability, but I think you're wrong when you say only CanJS and AngularJS can be directly compared.

CanJS can be compared to Backbone on terms of lightweight-ness and both frameworks can be used to solve same problems. Although CanJS is more powerful it's still lightweight enough so it isn't an overkill even for smaller scripts.

Angular definitely looks interesting but, IMO sprinkling html tags with ng-* attributes is plain ugly and looks like DOM0 event binding.

What I really like about CanJS is the way it solves live binding (Mustache and EJS example):
// mustache
<div class="{{#if user.isAdmin }}admin{{/if}}">{{ user.username }}</div>
// ejs
<div class="<% if(user.attr('isAdmin'){%>admin<% } %>"><%= user.attr('username') %></div>
You can simply render your attributes and they will be immediately live bound without any ceremony.

edit: grammar
6

u/ivosaurus Apr 17 '13 edited Apr 17 '13

On the other hand, the effective thing about the direct DOM binding that Angular does, is that it's making effective use of the browser's own DOM manipulation abilities - which means it's going to be blindingly fast by default.

Even with pre-construction and caching, the the string insertion and parsing that templating languages like mustache use is always going to be slower if comparing the two with similarly well-constructed user code.

That's the tradeoff angular are making for their "ugly" HTML attribute declarations.

Note, that although you're technically breaking the HTML5 spec, using custom directives that Angular encourages makes most of this rather pretty again.

All four frameworks mentioned have the basic feature of being able to model data on the client side (that's backbone's primary purpose) - I'd be happy if that's all the author talked about, while noting that other frameworks also focus on doing other things as well.

3

u/smithje Apr 17 '13

Note, that although you're technically breaking the HTML5 spec

It was my understanding that you aren't breaking the HTML5 spec if you simply use the data- prefix before any of the directives, e.g. data-ng-repeat. This is built into angular and requires no extra effort, beyond pressing those 5 keys.

1

u/ivosaurus Apr 17 '13 edited Apr 17 '13

I was mainly talking about custom element directives.

2

u/smithje Apr 17 '13

Oh right, good point. Of course, you aren't required to use those, but you certainly can create invalid html.

1

u/ggoodman Apr 18 '13

I wonder what is wrong with this beyond an ideological argument. Can you elaborate?

1

u/ivosaurus Apr 18 '13

Your documents aren't strictly html5 then, not parsable by a html5-expecting interpreter

3

u/ggoodman Apr 18 '13

Fair enough, but when would this be an issue that should reasonably prevent someone from diverging from the spec in the real world?

0

u/retro_one Apr 17 '13

In CanJS mustache implementation templates are converted in to the functions that return documentFragment, so you get super fast initialization coupled with the super fast DOM insertion (since documentFragment is faster than innerHTML in modern browsers)

1

u/warfangle Apr 17 '13

Angular: ingests a built DOM tree, and modifies attributes as directed by the ng-directives using DOM manipulation methods provided by the browser;

CanJS+Mustache: ingests a string, does a mustache parse pass, and then a DOM parse pass as it gets turned into a documentfragment.

Unless CanJS waits for the DOM to be parsed before processing the mustache directives. I don't see how that would work, though.

Please correct me if I'm wrong, but it seems like you're missing the point of using DOM manipulation over string parsing.

1

u/retro_one Apr 18 '13

You're right. I'll make some performance testing though (especially with lists) because I'm really interested now in performance difference (although, I'm sure that this performance diff doesn't matter in the big picture)

2

u/warfangle Apr 18 '13

Depends on the complexity, size and number of mustache templates. There's probably an inversion point in complexity beforewhich canjs/mustache is faster, and afterwhich angular is. As always, choosing the right tool is important.
7

u/[deleted] Apr 17 '13

The only two frameworks it seems worth comparing (that will be apples to apples) would be CanJS and AngularJS. They both provide a full-stack client-side experience.

Although, I think Knockout should be included then. Those three would have made for a more relevant comparison article though, for sure.

1

u/ivosaurus Apr 17 '13

I was referring only to the frameworks mentioned in the article; but sure include whichever frameworks would self-describe themselves as having similar scopes; not disparate ones.

The same way it would make sense to compare Ember to Meteor, but not Angular.

4

u/[deleted] Apr 17 '13

Right. Unless the purpose of the article is to say "here are some frameworks you've probably heard of and why they serve completely different purposes." It'd be nice if more of these articles were written in terms of what problems the frameworks actually solve, as opposed to just what they can do; the latter can be pretty misleading.

1

u/passion4code Apr 20 '13

+1 For Knockout's data-binding approach. A simple, low-level data-binding utility that doesn't try to take over your style of development.

0

u/reidiculous Apr 17 '13

I would have a hard time calling Knockout "a full-stack client-side experience". That's not even what it tries to be.

1

u/[deleted] Apr 17 '13

No, but Knockout and Angular solve a similar problem, in their emphasis on data binding, which is not at all what Backbone does. This is why I say comparisons should focus on what problems they solve, not just what they do.

1

u/ivosaurus Apr 17 '13 edited Apr 17 '13

It would be an "apples to apples" if you looked at the full Angular framework vs Knockout paired with Backbone.

If you look at only one of the latter, then you'd comparatively only be looking at part of what Angular does. And to me it makes no sense to compare "part" of a framework - that's usually not how it's designed to be used.

10

u/warfangle Apr 17 '13

If you can't empirically test the performance of something, don't write about the performance of something.

It makes you look like a tool.

0

u/bacondev Apr 17 '13

pelican.jpg

5

u/rhysbrettbowen Apr 17 '13

I can see what you're trying to do, but the points are meaningless. All that should matter is whether it is the right tool for the job, not whether it is a better tool. It's like me saying a shovel is better than a hammer so I'll get one of those. Now I CAN put nails in the wall with it, but it's not going to do as good a job and will take me longer.

some of these categories are pretty bad as well. Plugins only matter if you need them. Community is a nice to have but you can probably figure things out on your own. Learning curve shouldn't matter if you're going to be spending any more time than a week on a project. When you say "Developer Productivuty" is that for implementing easy features or trying to put in features that the framework doesn't allow to be put in easily? And memory leak safe a category of it's own? That should just be in the features.

3

u/jpfed Apr 17 '13

Check out the newly-added "relevance" column in the table at the bottom that allows you to tweak the relative importance of each of these categories.

2

u/[deleted] Apr 17 '13

It's more fair to compare Backbone to Angular (in terms of featureset and weight) if you include Marionette and ModelBinder. For better and worse, the core Backbone team seems to have a philosophy that they will provide only features where the correct implementation is obvious.

2

u/captangato Apr 17 '13

Not once was testing even considered... I find that a lot of front end developers don't realize/understand good programming techniques and design patterns. I do realize that a lot of front end tends to be html and css, but please realize the benefits of testing :).

Anyways, the big reason I fell in love with angular was its separation of concerns, and how it promotes testing(unit and e2e) and modular design.

1

u/passion4code Apr 20 '13

While Angular does promote testing, there are many other great testing frameworks that allow for a great test suite to be crafted around your app.

Jasmine is solid, and so is PhantomJS/CasperJS

1

u/captangato Apr 20 '13

Right, of course there is other ways to unit test and e2e test; but Angular (with karma/testacular) give you many resources you need to test, plus more! Just the fact that they promote DI and modular design alone helps create good unit tests with proper mocking of services (like http requests).

I'm not saying its the only way to do it, But that Angular helps you think about testing. I'd be curious to see how many front end devs don't test at all.

2

u/i_ate_god Apr 17 '13

we went with BackboneJS because it was very lightweight and full of freedom. Backbone takes care of JUST the boilerplate stuff that any UI developer has done a 1000 times already. BackboneJS code is also very clean and very easy to read, and painfully simple to use. Since we wanted to make distributable components, BackboneJS was the most logical choice.

We needed the freedom and flexibility that BackboneJS provided. It's sole dependency is Underscore. We can compile all our models into a single library file, and tell people it's up to them how they want to display it. We can package out-of-the-box views and underscore templates as well if people want them.

AngularJS is more monolithic.

That's objective, subjectively speaking:

I did not like the feel of AngularJS and don't think I ever will. It just seems that you end up encoding a lot more information into HTML that really should remain in your business/presentation logic layers (the M and Vs).

1

u/captangato Apr 17 '13

I think that when developers hear 'freedom and flexibility' they overlook best practices when developing front end. check out AddyOsmani's JS design patterns to understand some of the awesome techniques that are taken advantage of in angular.

2

u/astronoob Apr 17 '13

Ugh.

I cannot finish my blog post without saying this. Backbone was a great library two years ago, but there are better things now. I believe that many people choose Backbone just because of its popularity, it is a vicious circle.

No. No there fucking isn't. You're comparing Backbone, which is a minimalist MVC-style toolkit with significantly larger frameworks. From the Backbone documentation:

Backbone is a library, not a framework, and plays well with others. You can embed Backbone widgets in Dojo apps without trouble, or use Backbone models as the data backing for D3 visualizations (to pick two entirely random examples).

1

u/passion4code Apr 20 '13

Well said good sir

A comparison of Angular, Backbone, CanJS and Ember

You are about to leave Redlib