11 ms·
A Comparison of Angular, Backbone, CanJS and Ember
- Lazare 14y agoOnce again, nobody ever looks at Knockout. :)
- jimsteinhart 14y agoDoes anyone have any idea why it is that Knockout is often neglected in these comparisons?
- radicalbyte 14y agoAnti-Microsoft bias is my guess.
- tlrobinson 14y agoI've been using Knockout for months and I had no idea it was built by a Microsoft employee. And why should anyone care?
- andysinclair 14y agoProbably because it is chief maintainers are Microsoft employees?
- stevensanderson 14y agoWould that be considered negative? In any case, KO is not a Microsoft project, and only one of the core team members (me) works for MS. Anyway, many projects are built with KO, and its 3500+ watchers on GitHub suggests it's something like 7 times as widely used as one of the libraries in the article, so it's perhaps inaccurate to say that nobody considers it!
- WickyNilliams 14y agoI don't think it is, but others might. I've often sung KO's praises but it always seems fall to the wayside. Personally I think KO would greatly benefit from more architectural guidance (as i mentioned above). You're left on your own architecturally and structurally, with little guidance or higher level constructs to assist. This is much like backbone, but with backbone there is a lot of guidance out there, and even frameworks built atop of it (e.g. Marionette) which aim to instil best practices. Things I'd like to see, which might quell other's trepidation: * A large-scale demo app, with a detailed run-through of the how's and why's * A guide to unit testing ko apps * Drop IE6 (maybe even IE7?!) support to make it super lightweight. It's never going to be backbone lightweight, but imagine being able to say the tiniest front-end framework with no dependencies - that's a powerful message
- porker 14y agoBest practices and a large-scale app would be awesome! The people in the IRC channel are very helpful (and will happily tell a cleaner way to do it than the KO examples on their website), but to have all this written up would be excellent.
- WickyNilliams 14y agoThanks for the tip about the IRC channel, didn't realise there was one out there. I assume it's on freenode? But for most, hitting up an IRC channel is a barrier to entry they just won't have the enthusiasm to overcome. Such advice should be front and center, easy to access, up to date and canonical.
- porker 14y agoFreenode indeed :)
- Lazare 14y agoKnockouts documentation is fantastic, but geared at a very novice level. The lack of any guidance on unit testing is a particular frustration.
- polskibus 14y agoI think it is seen as different, because Knockout brands itself as MVVM, whereas other frameworks are usually mentioned in MVC context
- Guillaume86 14y agoI think it's dismissed because it is "just" a view/model binding library IMO as opposed to "full" MVC frameworks (with routing etc). Personal opinion: I used knockout before switching to Angular, I woudn't switch back, why bother with observables when you can just use plain JS?
- curveship 14y agoSince you asked, from my experience, there is one very good reason for KO-style functional observables rather than plain JS: immediate naming errors. If I type obj.prop when I should have typed obj.Prop, it simply returns undefined. But if I said obj.prop(), it excepts. This means that naming errors are diagnosed right at the site and immediately. I've found this a significant advantage to KO-style observables, particularly when refactoring code.
- Guillaume86 14y agoNaming conventions is usually enough for me. Not having to wrap every declaration/get/set (with Ajax data in particular) still outweight this little side effect IMO.
- rimantas 14y agoI've dropped Knockout simply because it is the easiest way to paint yourself in the corner. Its magic is ok for the simplest cases. Went with backbone, less magic, but solid foundation.
- Lazare 14y agoI'm working on a pretty major project with Knockout, and that's not really been my experience. The "magic" is basically "it has two-way data binding". Which is magic, but no more so than the same feature in Angular, Ember.js, or the relevant Backbone plugins. Two-way data binding is pretty magical; if you need it that's probably good, if you don't really need it, it's bad. Comparing vanilla Backbone to Knockout seems a bit odd; they have almost no overlap, and they don't really solve the same problems. Conversely, if you are using Backbone to solve a Knockout-style problem, it's either not really the sort of problem Knockout is designed for (ie, no need for two-way data binding) or you've added a bunch of magic onto Backbone (either through writing it yourself or using one of the many plugins for Backbone). I just don't think you can use Backbone, solve the sort of problems that Knockout is good for, and have less magic. Two-way data binding is magic, and it's like...90% of what Knockout does. Either your stack includes that magic, or you can't compare yourself to Knockout.
- WickyNilliams 14y agoI came here to say exactly that! Knockout is great, simple, fast, comparatively small, no dependencies, and has deep browser support (IE6+ iirc). The main problem is lack of architectural guidance, in my opinion
- landland 14y agoI did last week. From a newbie's perspective. This comparison was way better than mine. Mine focused more on the learning curve aspect and is a much shorter read. You can read it at http://www.martywong.com/blog/backbone-vs-ember-vs-angular-vs-knockout-review http://www.martywong.com/blog/backbone-vs-ember-vs-angular-v...
- knite 14y agoI expected to see Batman and/or Knockout on this type of comparison. Also, I may be biased because I haven't heard of CanJS, but this article seems suspiciously favorable toward it. Was the article written with a bit of promotion in mind?
- ganarajpr 14y agoI think the article is fine. The author states that he is comparing the frameworks he has USED. Not all MV* frameworks. About the author favoring CanJS, I think you may be right.
- blktiger 14y agoIt does seem that the author favors CanJS perhaps, but I thought his comparison was fair overall and he did note areas that CanJS falls short of Ember/Angular. I would suspect that if he were to break down his experence with the various frameworks, you would find CanJS taking up a much larger share than the other frameworks.
- bsaul 14y agoI had the exact same impression. Judging by its github account, he seems like a contributor to the CanJS project, so maybe he's a little biaised. In particular, the "maturity" part where he puts CanJS to the same level as AngularJS, (because CanJS is using some javascriptMVC code) seems a little far fetched.
- retro212 14y agoWhy? CanJS' codebase is extracted from JavaScriptMVC which is ~5 years old and used on a lot of big codebases. It did go through a lot of changes but every change was made because of the real-world-need. source: Bitovi employee / core contributor
- ganarajpr 14y agoCommunity wise, if you give a 5 to Backbone and 4 each to Angular and Ember - I would be somewhat ok with that.. But still a 3 to CanJS is a bit far-fetched... CanJS github has ~500+ stars. 25 questions on SO. In comparison Github stars: Backbone - 13k+ Angular - 8.5k+ Ember - 6.5k+ StackOverflow questions : Backbone - 8.3k Angular - 4.4k Ember - 3.4k Based on this atleast I would give a rating of 5 - BB , 4 - NG , 3 - Ember and 1 or 0 to Canjs under community section. If you add Google Groups stats to this , then Angular wins out in community.
- Kiro 14y agoOf all the JS frameworks the only one that felt "natural" was Angular. I instantly saw the benefits compared to doing it the jQuery way.
- xsace 14y agoSome comparison points are missing. Like testability.
- ubersoldat2k7 14y agoOr i18n and form validation, which I find none of this frameworks solve in a meaning full way.
- virtualwhys 14y agoThat's what has me on the fence between existing Scala/Play framework server-side and some-js-framework client-side. Would be thrilled with my stack if it weren't for the slow-ish build times, so the thought of offloading the view to the client has some appeal. For now coffeescript does the trick for client-side functionality -- may entertain a client-side MVC framework with a less complex/involved project to test the waters.
- Kototama 14y agoYes, I would love to see how this framework works with other language such as CoffeeScript or ClojureScript. I personnaly had a bad experience with Backbone + ClojureScript because Backbone was way too much object-oriented to be meaningfull for a ClojureScript app.
- rplnt 14y agoI don't really care about the comparison itself (sorry), but the adjustable results are an awesome idea. I've never seen it before.
- tiedemann 14y ago+1 for adjustable bias
- vovafeldman 14y agoAfter comparing the frameworks and talking with client-side expert, my company decided to go for Ember. Please share what you think about our decision before it's too late.
- redeemedfadi 14y agoI'm making the same decision now. I've used Ember before and it has been a little painful. I'm going to give Angular a try now. It seems most people on Hacker News prefer Angular to Ember.
- Lazare 14y agoAngular is "hot", but it's not without it's drawbacks. For example: https://koglerjs.com/verbiage/angular https://koglerjs.com/verbiage/angular The author's point is that there's a fine line between "writing an MVC framework" and "writing a compiler", and the AngularJS authors blew past it without even noticing. And as a result, they now have a pretty crappy compiler. :)
- st3redstripe 14y agothis is a plug for can.js right?
- desireco42 14y agoI agree it's been a long time to move away from backbone, it is awesome, made by awesome person(s), but things have moved along in the meantime. I think Knockout, Batman and SpineJS which is like Backbone upgraded should be seriously considered. Lately I use Meteor :)
- corresation 14y agoI do not mean this to sound cynical, but are people actually building full-fledged web apps with these frameworks? Where are they? Any public examples? The thing is that these tools generally solve the easiest part of problem space, yet paradoxically they make the novel and interesting parts much more difficult. They may pay off if your job is an assembly line banging out trivial CRUD apps, but I just don't see the real value for any reasonable scale project. I looked at Angular a while back and while it got rid of a few lines of code, it made the necessary edges of a modern web app incredibly ugly (and truly the biggest waste of time is fighting with your framework). That's one of the reasons I like Backbone's minimalism -- it is more a simple toolbag and less an all encompassing solution that relieves you of any reason to make decisions. Backbone also works very well in a non-pure client-side web app, which are much more common. Seeing these comparisons I am increasingly getting the impression the discussion is dominated by people procrastinating from their projects, argue over the number of lines of "boilerplate" necessary to create an iterator, which is something that will have negligible significance later on.
- ganarajpr 14y agoCould you define the "novel and interesting parts"? Perhaps examples of what they are ? If you are fighting with Angular there is probably a reason. You probably did not read this : http://stackoverflow.com/questions/14994391/how-do-i-think-in-angularjs-if-i-have-a-jquery-background http://stackoverflow.com/questions/14994391/how-do-i-think-i... In my day job, I am working in Knockout now and as a general principle I dont do DOM Manipulation in my ViewModels. I can, and knockout allows me to. But I dont. I think that just this one single and simple rule has made me a better programmer. Do you remember Mr. Miyagi in Karate Kid? When he was teaching the kid to learn Karate he wasnt teaching him Karate moves was he? He was teaching him "wax on", "wax off". If the kid had thought "I know better" and fought against this rule he would never have learnt karate. He would have gone home, got beaten up by the kids in his block and also have lost that tournament in the first round. Its the same with Angular and its rules. If you want to win - dont fight it.. persevere till you understand the significance of wax on and wax off and in the end, trust me, you will feel it . You will end up being a better programmer. To start with your wax on, wax off - read that SO answer.
- andrew_wc_brown 14y agoI built a web-app for my previous startup in Backbone, after a year and half working with it, (1) I got frustrated with the amount of files I had to create, (2) its performance, and (3) the difficulty to write pure tests, (3) no concreate convention. EmberJs doesn't relieve me of any of these problems other than convention, but I'm currently working on contract work that has me using EmberJS I didn't like Angular for many reasons, but they promised to solve my big 4 problems. What I didn't like at first about Angular. Cocumentation is written from what I'd expect from a computer science major, I had to litter my dom with tons of tags and I had to overcome the idea of their syntax as ugly. But it did everything I needed. I reduce my javascript by 70%. I got ride of most of my other 3rd part libraries. Performance was awesome. I didn't need to figure out how to compile all my templates into one js file. It made testing dead easy since all I was left was logical javascript.
- charlysisto 14y agoI gave up using Backbone a year ago. Being a server side dev, the 'to much boilerplate' quickly killed the initial enthusiasm. But while waiting for Ember to mature, I stumbled on Angular and completely bought it's original & refreshing approach that is, being ahead of what the modern browser should be : embracing html components (aka directives), observables & the beauty of dependency injection. That for me was the initial 'wow factor' beyond the nice feeling you get when binding your first view/model. If I was to market angular I'd say it really caught the right angle of frontend webdev
- lee 14y agoThe very first comparison of assigning scores based on number of features doesn't add value. For example, Backbone is designed to be light-weight and this metric doesn't take that into account. It would be like complaining that git is inferior because it doesn't have all the features of IBM's Clearcase.
- ramayac 14y agoExactly! I would give anything if I could use git every day at work instead of CC.
- lshemesh 14y agoI've been using Backbone exclusively for building Tutorialize's (https://tutorialize.me https://tutorialize.me) chrome extension. One year ago backbone seemed like a very obvious choice, nowadays it's not the clear winner. I'm thinking about moving away from Backbone and trying out Angular or Ember. I've even thought about playing around with Dart. The most difficult thing for me has been dealing with all the things that Backbone doesn't handle out of the box. Things like zombie views, data binding, and namespacing just to name a few. The worst thing however has been the constant need to deal with strange quirks and bugs that I've found almost impossible to track down. I've posed a question to the #documentcloud irc channel three times and did not receive a single reply. I believe in the long run that the strength of a framework is about the conventions put in place. After all, isn't it about making development easier?
- erdogan 14y agoVery nice comparison. Is it really time to move on from Backbone? I'm about to migrate a project to it because I believe in its potential to force me to write better js code in the long run. Should I not?
- GnarlinBrando 14y agoThe question you should ask yourself is; "Is it right for you and your project?" It doesn't matter as far as your project if the community should be moving on as a whole or not. What matter's is if you, and/or your team, can effectively use the technology to reach your goals.
- dustingetz 14y agoi use backbone for a in-development app that is larger and has a more complex UI than the examples on the backbone site. (it's in early stages, but we think we've prototyped enough to know it's going to work nicely.) Most definitely "serious"; we're talking 10 engineers for a year type of size. > Backbone requires you to write a lot of boilerplate code, which I think is totally unnecessary. This is in my opinion a direct threat against developer productivity. a lot of people parrot this but i think they're missing the point. Backbone doesn't require you write boilerplate; it requires you to handle dom manipulation yourself. if you do dom manipulation wrong there's a lot of boilerplate; or you can use one of many libraries that make this very easy. backbone isn't meant to be the only dependency, it's meant to play well with other dependencies. So some of our Backbone.Views use knockoutjs (with knockback.js) for HTML rendering, and other Backbone.Views use KendoUI widgets instead of raw HTML. Nowhere are we doing raw dom manipulation and our view hierarchies are logical, not too deep, and rendering is quite clean. Notably we are not using Marionette; the "boilerplate" Marionette tries to reduce, for us, is actual decision points that are essential complexity. Flexibility in rendering implementation is very important as we're working with a very talented external graphic design firm to provide a clickable HTML prototype. We really don't want to be in the business of rewriting their delivery to suit our framework's rendering choices.
- tlrobinson 14y agoHow about Knockout?
- deleted 14y ago[deleted]
- andreypopp 14y agoI think that comparing Backbone to such feature rich frameworks like Angular or Ember doesn't make much sense — you certainly would want to choose some view technology (maybe even with data bindings) on top of Backbone.View and so on. Actually I like how Angular.js extends HTML further with high-level declarative constructs so I built something like this but for Backbone — Backbone.ViewDSL http://andreypopp.github.io/backbone.viewdsl/ http://andreypopp.github.io/backbone.viewdsl/ — it also allows you to add directives as new HTML elements and attributes but otherwise plays well with other libraries, that means it is not yet another "closed" ecosystem but just a simple plugin for Backbone. You can also take a look to an implementation of TodoMVC with Backbone.ViewDSL in just 113 lines of code — https://github.com/andreypopp/todomvc/blob/gh-pages/labs/architecture-examples/backbone.viewdsl/js/app.coffee https://github.com/andreypopp/todomvc/blob/gh-pages/labs/arc...
- joshontheweb 14y agoIf you like Rails, you will probably like ember.js, if you like bottle.py or flask, you will probably prefer backbone.js. I prefer backbone.js.