A Comparison of Angular, Backbone, CanJS and Ember(sporto.github.io)
sporto.github.io
A Comparison of Angular, Backbone, CanJS and Ember
http://sporto.github.io/blog/2013/04/12/comparison-angular-backbone-can-ember/
20 comments
I 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.
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.
I 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?
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?
I 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.
Why? 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
source: Bitovi employee / core contributor
I 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.
About the author favoring CanJS, I think you may be right.
It 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.
i 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.
> 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.
Once again, nobody ever looks at Knockout. :)
I 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
Does anyone have any idea why it is that Knockout is often neglected in these comparisons?
I think it is seen as different, because Knockout brands itself as MVVM, whereas other frameworks are usually mentioned in MVC context
Anti-Microsoft bias is my guess.
I've been using Knockout for months and I had no idea it was built by a Microsoft employee. And why should anyone care?
I'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.
I'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.
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.
Probably because it is chief maintainers are Microsoft employees?
Would 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!
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!
I 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
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
Best 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.
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.
Thanks 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.
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.
Freenode indeed :)
Knockouts documentation is fantastic, but geared at a very novice level. The lack of any guidance on unit testing is a particular frustration.
I agree. The documenation is awesome. Concise, accurate and not confusing (i'm looking at you angular). And the interactive online tutorial is the icing on the cake. I posit that a complete beginner could get up and running with KO within a few hours.
But again, for non-beginners, I'd like to see more in-depth stuff.
But again, for non-beginners, I'd like to see more in-depth stuff.
In some circles it would be considered negative.
For example, I have spent most of my career using Microsoft developer tools building LOB applications. I think the MS dev toolset is great.
At one point I was involved in building a consumer web app and attended various "startup" community events. I would start chatting to people (generally Rails/PHP devs) and as soon as I mentioned I was building a web app using MS tech they would look at me as if I was mad. Sometimes they would even make excuses to stop chatting and find somebody else to talk to - I concluded from this that there is definitely some anti MS feeling within the startup community.
Anyway, this has gone off topic, but thought it was worth mentioning. BTW, one of my colleagues has just started using Knockout and thinks it is great!
For example, I have spent most of my career using Microsoft developer tools building LOB applications. I think the MS dev toolset is great.
At one point I was involved in building a consumer web app and attended various "startup" community events. I would start chatting to people (generally Rails/PHP devs) and as soon as I mentioned I was building a web app using MS tech they would look at me as if I was mad. Sometimes they would even make excuses to stop chatting and find somebody else to talk to - I concluded from this that there is definitely some anti MS feeling within the startup community.
Anyway, this has gone off topic, but thought it was worth mentioning. BTW, one of my colleagues has just started using Knockout and thinks it is great!
I 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?
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?
Since 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.
Naming 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.
I 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-v...
Of all the JS frameworks the only one that felt "natural" was Angular. I instantly saw the benefits compared to doing it the jQuery way.
I 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 :)
I think Knockout, Batman and SpineJS which is like Backbone upgraded should be seriously considered.
Lately I use Meteor :)
I 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
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
I 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/ — 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/arc...
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/ — 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/arc...
I've been using Backbone exclusively for building Tutorialize's (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?
Some comparison points are missing. Like testability.
Or i18n and form validation, which I find none of this frameworks solve in a meaning full way.
That'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.
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.
Yes, 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.
I personnaly had a bad experience with Backbone + ClojureScript because Backbone was way too much object-oriented to be meaningfull for a ClojureScript app.
The 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.
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.
Exactly! I would give anything if I could use git every day at work instead of CC.
After 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.
I'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.
Angular is "hot", but it's not without it's drawbacks. For example:
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. :)
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. :)
this is a plug for can.js right?
Very 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?
The 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.
If 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.
How about Knockout?
I 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.
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.
I'm not totally sure it will have been the right choice in retrospect but it was effectively this blog post:
http://corner.squareup.com/2012/04/building-analytics.html
that lead me to prototype using ember. I believe Square's analytics platform - not a "full" web app but a pretty substantial one - is still in production deployment based on ember. Of course, they're probably using whatever version of ember was around 18 months ago, and there have been radical changes since...
It feels very likely to me that these javascript frameworks represent a substantial component of the future of this kind of development. People smarter than I am seem to feel that angular is 'better technology' than ember, or at least that in looking like extensible html it has more in common with the eventual future than ember does.
I'm actually surprised, in this spate of MVC framework posts, that Meteor hasn't gotten more of a mention. In some ways it's younger than the others, and it has some idiosyncrasies (it doesn't actually require that the client and the serve both be written in javascript but you'd never know if from the web site). But the meteor team is incredibly smart and the company is well financed - and they're spending a lot of time and energy on one of the most interesting aspects of the problem, something ember and angular have not worked out: how to synchronize models and data between the client and the server. Meteor has a special protocol for handling this, such that when deployed properly if the data changes in a database the model in the client automatically updates to reflect this.
As someone building a complicated analytical engine with computations done in a python / C++ back-end and structure results visualized in javascript, the idea of being able to reuse models in both places is appealing and the idea that I wouldn't have to spend as much time on data synchronization is almost enough to try to make the switch...
http://corner.squareup.com/2012/04/building-analytics.html
that lead me to prototype using ember. I believe Square's analytics platform - not a "full" web app but a pretty substantial one - is still in production deployment based on ember. Of course, they're probably using whatever version of ember was around 18 months ago, and there have been radical changes since...
It feels very likely to me that these javascript frameworks represent a substantial component of the future of this kind of development. People smarter than I am seem to feel that angular is 'better technology' than ember, or at least that in looking like extensible html it has more in common with the eventual future than ember does.
I'm actually surprised, in this spate of MVC framework posts, that Meteor hasn't gotten more of a mention. In some ways it's younger than the others, and it has some idiosyncrasies (it doesn't actually require that the client and the serve both be written in javascript but you'd never know if from the web site). But the meteor team is incredibly smart and the company is well financed - and they're spending a lot of time and energy on one of the most interesting aspects of the problem, something ember and angular have not worked out: how to synchronize models and data between the client and the server. Meteor has a special protocol for handling this, such that when deployed properly if the data changes in a database the model in the client automatically updates to reflect this.
As someone building a complicated analytical engine with computations done in a python / C++ back-end and structure results visualized in javascript, the idea of being able to reuse models in both places is appealing and the idea that I wouldn't have to spend as much time on data synchronization is almost enough to try to make the switch...
I too am a little surprised at how little attention Meteor seems to get. I attribute this to the fact that it sells itself as a client + server technology, rather than a potential client-side only tech (being fed by whatever server you want). When you sell yourself as a client+server then you might have a difficult time attracting the attention of all those who have significant investment in a different back-end, be it Node, Rails, or whatever. But yes, I agree, Meteor looks awesome. It's also got a steep learning curve. And much like Ember or even--I would argue, Angular--it's difficult to see the "magic" right off the bat. And given how new Angular and Ember and Meteor are, there is still a dearth of tutorials, videos, and books to help new comers see the value and get started.
So I'm definitely keeping my eye on Meteor.
That said, correct me if I'm wrong, but doesn't Ember have something similar? If the data changes in the database then won't Ember update the client to reflect this? I'm not exactly clear on the distinction between Meteor's "Live HTML" and Ember's approach.
So I'm definitely keeping my eye on Meteor.
That said, correct me if I'm wrong, but doesn't Ember have something similar? If the data changes in the database then won't Ember update the client to reflect this? I'm not exactly clear on the distinction between Meteor's "Live HTML" and Ember's approach.
I am probably wrong, but it would be interesting if Meteor allowed other back-ends. There would need to be a shim API (like a way to publish and listen for changes, a way to represent records for ex..) but it seems if MongoDB works other NoSQL dbs at least (and SQL too) could work.
Well, Google used Angular to re-write DoubleClick, so that's a pretty good example of a large scale application using one of these frameworks in the wild.
Ember.js is being used in http://www.discourse.org
Anecdotally, my team and I are using Angular.js for our mobile offerings of http://kona.com and have been loving it.
I'm not sure why it would be any more difficult to build full-fledged web apps with these frameworks than it would be to use vanilla jQuery or Backbone. Our app has become quite complex and we're still loving Angular.js, for instance. And it's not simply about "getting rid of lines of code", it's also about structure and testability.
I can honestly say we haven't had to fight with angular yet but who knows what will happen down the line. For now, we're very happy.
> Seeing these comparisons I am increasingly getting the impression the discussion is dominated by people procrastinating from their projects
Not sure why this barb is necessary..
Ember.js is being used in http://www.discourse.org
Anecdotally, my team and I are using Angular.js for our mobile offerings of http://kona.com and have been loving it.
I'm not sure why it would be any more difficult to build full-fledged web apps with these frameworks than it would be to use vanilla jQuery or Backbone. Our app has become quite complex and we're still loving Angular.js, for instance. And it's not simply about "getting rid of lines of code", it's also about structure and testability.
I can honestly say we haven't had to fight with angular yet but who knows what will happen down the line. For now, we're very happy.
> Seeing these comparisons I am increasingly getting the impression the discussion is dominated by people procrastinating from their projects
Not sure why this barb is necessary..
It wasn't intended as a barb. If anything it was self-reflection, in that I tend to find myself caught up in essentially trivial things when I get caught in procrastination loops. Perhaps I am projecting.
I read it wrong then. At any rate, fwiw I actually think Ember.js and Angular.js help with procrastination. It's far to easy to get muddled in the details of how to organize a backbone.js or vanilla jQuery application; at least for me. Going with Angular.js let me move forward faster than I would have otherwise.
This is a trade-off that manifests downstream. Highly opinionated there-is-one-right-way frameworks make it easy to get started because you don't have choice, but also get in your way in the long run because you don't have choice, and that also tends to limit what you can do.
At the same time if you don't have much experience with non-opinionated frameworks, you might end up in a state where your code is even less flexible than it would have been with opinionated frameworks.
I built http://www.5by.com on AngularJS in about 3 months, and just a few thousand lines of code. The same thing in Backbone would have likely taken a lot more time and a lot more code.
It was my first AngularJS app, and I was learning it on the job, which is why it took that long. Overall, Angular is a joy to work with and its conventions force you to write clean, readable, decoupled code.
It was my first AngularJS app, and I was learning it on the job, which is why it took that long. Overall, Angular is a joy to work with and its conventions force you to write clean, readable, decoupled code.
I find it highly annoying that people who promote client-side MVC and one-page apps always claim that it's trivial to make pages linkable and make browser navigation work, yet the wast majority of real-life single-page apps are missing those features.
That's because it's not generally a requirement for single-page applications. The idea of a single-page app is to make it feel like a desktop application, not to make it highly linkable (which is why it was stupid for Twitter and Gawker to go the single-app route). But yes, it is incredibly trivial to support it using these frameworks.
That's because it's not generally a requirement
Is that a new way of saying "I just don't care about it"?
The idea of a single-page app is to make it feel like a desktop application, not to make it highly linkable
I've heard that before... from ASP.NET WebForms developers. Incidentally, I've seen quite a few ASP.NET WebForms applications that were literally a single page with changing panels and hidden controls. Needless to say, they were a bloody mess. Thing that normally could be achieved by linking required code changes. Integrations that could be performed via a simple HTTP post were done using complicated web services.
Links are the essence of the web platform. Calling something an "app" doesn't change that.
Is that a new way of saying "I just don't care about it"?
The idea of a single-page app is to make it feel like a desktop application, not to make it highly linkable
I've heard that before... from ASP.NET WebForms developers. Incidentally, I've seen quite a few ASP.NET WebForms applications that were literally a single page with changing panels and hidden controls. Needless to say, they were a bloody mess. Thing that normally could be achieved by linking required code changes. Integrations that could be performed via a simple HTTP post were done using complicated web services.
Links are the essence of the web platform. Calling something an "app" doesn't change that.
> Is that a new way of saying "I just don't care about it"?
It's one way of saying it, I suppose, yes. We don't worry about linking to states in desktop apps so why would we care about linking to states in desktop-like javascript apps?
> Links are the essence of the web platform. Calling something an "app" doesn't change that.
I agree. But when you make a desktop-like app that lives on the web, then linking isn't as important. I take it your issue is with desktop-like apps on the web?
It's one way of saying it, I suppose, yes. We don't worry about linking to states in desktop apps so why would we care about linking to states in desktop-like javascript apps?
> Links are the essence of the web platform. Calling something an "app" doesn't change that.
I agree. But when you make a desktop-like app that lives on the web, then linking isn't as important. I take it your issue is with desktop-like apps on the web?
My overall problem is that a lot of modern web development trends undermine the reasons web became so popular in the first place.
Linking is an easy example. Something that didn't require any "extra" effort now requires "correct" usage of some framework and extra effort. But there are many other things as well.
Linking is an easy example. Something that didn't require any "extra" effort now requires "correct" usage of some framework and extra effort. But there are many other things as well.
Yeah, but seriously, why would you want to link to a particular state in a desktop-style application? Especially if the intent of the app is to be used by a single user working with private data.
Take google docs. During any given session there could be thousands of different states the app is in at any one time, such as certain formatting options being selected, different popover or dropdown menus shown, or the content in the document itself changing. There'd be no point in providing a different URL for each one of those states.
Take google docs. During any given session there could be thousands of different states the app is in at any one time, such as certain formatting options being selected, different popover or dropdown menus shown, or the content in the document itself changing. There'd be no point in providing a different URL for each one of those states.
Yeah, but seriously, why would you want to link to a particular state in a desktop-style application? Especially if the intent of the app is to be used by a single user working with private data.
For example, to save some kind of setup you often use as a bookmark. This is especially valuable in case there are multiple setups you often alternate between.
To make it more concrete, imagine a table with multiple columns you can sort by and a bunch of search filters at the top. Your users from accounting always sort by date. Your users from HR always filter by a particular status and last name. Your CEO wants to be able to see both views.
If the application supports proper URLs, all of this can be done via bookmarks with no extra coding. Moreover, if someone suddenly develops the need for a new weird workflow, they can service themselves simply by bookmarking the URL.
For example, to save some kind of setup you often use as a bookmark. This is especially valuable in case there are multiple setups you often alternate between.
To make it more concrete, imagine a table with multiple columns you can sort by and a bunch of search filters at the top. Your users from accounting always sort by date. Your users from HR always filter by a particular status and last name. Your CEO wants to be able to see both views.
If the application supports proper URLs, all of this can be done via bookmarks with no extra coding. Moreover, if someone suddenly develops the need for a new weird workflow, they can service themselves simply by bookmarking the URL.
Yeah, definitely a good use case for URLs. Good thing it's so very easy to support with these newer frameworks.
My issue is that content entombed in a desktop-like app, which can't be scraped and repurposed from its stable URL, isn't part of the World-Wide Web, and indeed this is the trend that is going to destroy the Web and replace it with a home screen that is nothing more than a list of client/server silos.
If you use Ember correctly, you get a URL for each application state and can use the back button to your liking. The only downside that I can see here is that after going back, the site might take a while until it has fetched all the data (which is not the case for common web apps). Discourse suffers from that.
> The same thing in Backbone would have likely taken a lot more time and a lot more code.
I think that's an unfounded (not to mention unfair) statement, unless you've actually attempted to do so and can provide some objective data points. Otherwise, it's nothing but opinion.
Aside from that, the app does look interesting; I'll have to check it out later.
I think that's an unfounded (not to mention unfair) statement, unless you've actually attempted to do so and can provide some objective data points. Otherwise, it's nothing but opinion.
Aside from that, the app does look interesting; I'll have to check it out later.
Unless we get a large number of developers to build the same application twice using each framework, all evidence related to this is going to be speculative or anecdotal at best. Having written a lot of both backbone and angular, I can confidently say that I am _much_ more productive with angular, so much that I get incredibly frustrated and resentful when I have to work on a backbone project. I think if you do a little bit of research you'll find a sizeable amount of similar testimony from people who have switched from backbone to a more comprehensive framework.
Once you start supporting persistence and keeping things reliably in sync, things start to get very complicated. You'd still have to write that out in Backbone, when ember or angular provide it out of the box.
I like your app. Big fan of the 'timed' time-wasters! Great for short breaks. Thanks for introducing me to it!
5by is very nice -- great work
I've spend the last 40 minutes watching various videos brought to me by your app. Fantastic.
Where are they? Any public examples?
http://builtwith.angularjs.org/
http://builtwith.angularjs.org/
Not sure if that helps the case or makes it works:
Cafe Townsend. A page for a concert. Recipe sharing website. HTML5 Canvas Gradient Creator.
Those seems like toy examples one would do that something works, any real/serious public examples?
Cafe Townsend. A page for a concert. Recipe sharing website. HTML5 Canvas Gradient Creator.
Those seems like toy examples one would do that something works, any real/serious public examples?
I always hated that page. It makes angular look like a joke. Ember actually has real sites under it's belt, and I think angular shoots itself in the foot having those novelty 'apps' on there and not a single serious thing.
Although, Analytics is built with angular if I'm not mistaken.
Although, Analytics is built with angular if I'm not mistaken.
disclaimer: I work for Bitovi, and I'm a CanJS core comitter
Short answer: yes, people do build real apps with these frameworks.
I stumbled upon JavaScriptMVC (CanJS was extracted from JMVC) 4 years ago when I was building application with a lot of front end code, I think we had around 10k lines of JavaScript in various modules. Trying to build something like that without a framework was a huge pain, and JMVC helped here a lot.
In last few years (after I started working for Bitovi) I worked on pretty big enterprise level applications, and besides being able to build things in cleaner way, a huge plus was ability to allow less experienced developers (from the companies we did consulting for) to implement stuff with familiar structure and without needing to care about memory leaks, zombie events and similar stuff.
IMO CanJS is the best framework currently available, but I'm extremely biased. In the end I don't think it matters which framework people choose because they will get a lot of value just by using any of them.
That said, I would never again use a DOM-centric approach for frontend apps. Live binding is a huge game changer and data centric apps are (in my experience) less buggy and get stuff done with less code.
Short answer: yes, people do build real apps with these frameworks.
I stumbled upon JavaScriptMVC (CanJS was extracted from JMVC) 4 years ago when I was building application with a lot of front end code, I think we had around 10k lines of JavaScript in various modules. Trying to build something like that without a framework was a huge pain, and JMVC helped here a lot.
In last few years (after I started working for Bitovi) I worked on pretty big enterprise level applications, and besides being able to build things in cleaner way, a huge plus was ability to allow less experienced developers (from the companies we did consulting for) to implement stuff with familiar structure and without needing to care about memory leaks, zombie events and similar stuff.
IMO CanJS is the best framework currently available, but I'm extremely biased. In the end I don't think it matters which framework people choose because they will get a lot of value just by using any of them.
That said, I would never again use a DOM-centric approach for frontend apps. Live binding is a huge game changer and data centric apps are (in my experience) less buggy and get stuff done with less code.
Yes, there are people building full-fledged web apps...at least with AngularJS and Backbone. Hubspot uses a lot of Backbone in their products, and they're a large company at this point. Google uses AngularJS...the Youtube app for PS3 is written in Angular, for example.
If you find yourself fighting with Angular, it's because you're new to it. Angular is a very rich library...I believe it's definitely possible to do the equivalent of "programming Java in Python" coming from another client library to Angular.
If you find yourself fighting with Angular, it's because you're new to it. Angular is a very rich library...I believe it's definitely possible to do the equivalent of "programming Java in Python" coming from another client library to Angular.
Not only for the PS3, you can access it online: https://www.youtube.com/tv
OMG dint know that... Thank you sooo freaking much!!!
Same here. Angular is cool it seems for 'look at pictures my dog took on its collar camera' or 'look how small my todo list code is'. Otherwise it is a world of pain fighting with it.
Basically once you learn Angular you are an Angular programmer from then on. It has its own terminology and way of doing things, I haven't seen the benefit of going that way.
Also looked at its code, founds so much convoluted stuff in that it is a little scary having to run on top of it.
Basically once you learn Angular you are an Angular programmer from then on. It has its own terminology and way of doing things, I haven't seen the benefit of going that way.
Also looked at its code, founds so much convoluted stuff in that it is a little scary having to run on top of it.
> Basically once you learn Angular you are an Angular programmer from then on
Kind of like "once you learn Rails you are a Rails programmer from then on"?
I agree that if you're doing nothing but fight with a framework it's probably not a good choice for you. Correct me if I'm wrong but you sound like someone who isn't a big fan of opinionated frameworks in the first place.
Kind of like "once you learn Rails you are a Rails programmer from then on"?
I agree that if you're doing nothing but fight with a framework it's probably not a good choice for you. Correct me if I'm wrong but you sound like someone who isn't a big fan of opinionated frameworks in the first place.
> Correct me if I'm wrong but you sound like someone who isn't a big fan of opinionated frameworks in the first place.
I think you are right. I have been burnt by enough frameworks both picked by me or others that promise the world ('really easy, just use this framework! here is an example of a thing X that we did for a demo that kind of looks like something you might want to do').
Then as soon as you do something not anticipated or unimplemented yet in the framework you hit a wall and decelerate from 100 to 0 pretty quickly.
I guess a good framework is one that is extensible and straddles the border between a framework and library.
I think you are right. I have been burnt by enough frameworks both picked by me or others that promise the world ('really easy, just use this framework! here is an example of a thing X that we did for a demo that kind of looks like something you might want to do').
Then as soon as you do something not anticipated or unimplemented yet in the framework you hit a wall and decelerate from 100 to 0 pretty quickly.
I guess a good framework is one that is extensible and straddles the border between a framework and library.
> I have been burnt by enough frameworks both picked by me or others that promise the world
I've definitely been there, too. I think it's one of the risks in using a framework, but like everything you have to weigh the risks against the rewards.
> I guess a good framework is one that is extensible and straddles the border between a framework and library.
I think Rails did a good job with this. It provides opinionated defaults but allowed people to swap in other libraries as they needed.
I've definitely been there, too. I think it's one of the risks in using a framework, but like everything you have to weigh the risks against the rewards.
> I guess a good framework is one that is extensible and straddles the border between a framework and library.
I think Rails did a good job with this. It provides opinionated defaults but allowed people to swap in other libraries as they needed.
I work for a agency that does pretty substantial projects ($1-10M range) and we've done a fair amount of backbone. Angular has gotten a lot of chatter, but isn't really suitable for our kinds of projects.
I've helped build a 100 K line single page app in ExtJS, and I can see the value ember would have for building that app (have not looked much into angular so cannot comment on that one). What you need in large-scale single page apps are coping mechanisms for the DOM (or as I know it: the root of all evil). Stuff like automatic and on-demand rendering of content, automatic cleanup and event listener removal, nested layouting solutions, strong eventing and routing mechanisms, data binding and automatic data loading, and so on. Any framework that helps you with those things by necessity will invent its own pseudo-DSL, and require you to live in its world.
The way I see it, it's all a matter of what you're optimizing for. If you expect to run at most 2000 lines of code in a single page, then backbone is excellent for that. If you expect to run at least 20.000 lines of code in a single page, then something like ember or ext is needed. You can build those in backbone ofcourse, but you'll probably end up rebuilding much of the infrastructure the bigger frameworks give you out of the box.
Ofcourse, this is separate from the whole debate on whether a pure client-side approach makes sense on that scale. I still think it does, but I think the mixed model is equally valid (different trade-offs in each case). You're right that the mixed model blends poorly with these frameworks.
The way I see it, it's all a matter of what you're optimizing for. If you expect to run at most 2000 lines of code in a single page, then backbone is excellent for that. If you expect to run at least 20.000 lines of code in a single page, then something like ember or ext is needed. You can build those in backbone ofcourse, but you'll probably end up rebuilding much of the infrastructure the bigger frameworks give you out of the box.
Ofcourse, this is separate from the whole debate on whether a pure client-side approach makes sense on that scale. I still think it does, but I think the mixed model is equally valid (different trade-offs in each case). You're right that the mixed model blends poorly with these frameworks.
Discourse[1] uses Ember for all of its front-end and it seems to work pretty well.
[1]: http://www.discourse.org/
[1]: http://www.discourse.org/
StartHQ (https://starthq.com) is a web app directory and launcher. We are very happy with AngularJS, having used Backbone before. If there's enough interest, I could do a blog post about our experiences.
We are actually adding the ability to list which technologies any given app uses, so you will soon be able to search for all apps in production using any of the frameworks listed above.
We are actually adding the ability to list which technologies any given app uses, so you will soon be able to search for all apps in production using any of the frameworks listed above.
Build with Backbone http://harpb.com/player/showroom/
Betterment.com completely rewrote it's front-end app with backbone from Flex - https://engineering.betterment.com/2013/02/a-better-front-en...
There's nothing trivial about keeping data reliably in sync in the browser. It's a hard problem, not something that can be solved by writing a few lines of code in Backbone. It's very misleading to just dismiss it like that.
What would you call "the necessary edges of a modern web app"? I agree that these frameworks don't meet all my web app pain points, but thought I was the only one.
Last time I checked, Udacity was built on angular.
There's a list of Backbone examples at http://backbonejs.org/#examples
Could 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-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.
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-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.
I 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?
I'm building a large, complicated app for paying customers with Ember.js. Now that I've actually climbed the learning curve, I'm incredibly happy with the choice. The application has some large, CRUD-like components, but it also involves things like custom touch widgets and extensive drag and drop.
However, it should be kept in mind that Ember.js (and more specifically, the unreleased Ember Data library) is not a mature framework. 95% of the features I want to implement practically fall from my fingertips, and it feels glorious. The remaining 5% require diving deep into the internals of Ember Data. I'm tolerably good at that sort of thing, so it's a reasonable choice for me. But people who don't feel up to reading the source should probably avoid using Ember Data and stick with using jQuery to load JSON into regular Ember.Object instances (which works fine).
I haven't seen any big Angular apps first hand, but I know some former Backbone users who are diving in, and they also sound quite enthusiastic about their choice.
I'm building a large, complicated app for paying customers with Ember.js. Now that I've actually climbed the learning curve, I'm incredibly happy with the choice. The application has some large, CRUD-like components, but it also involves things like custom touch widgets and extensive drag and drop.
However, it should be kept in mind that Ember.js (and more specifically, the unreleased Ember Data library) is not a mature framework. 95% of the features I want to implement practically fall from my fingertips, and it feels glorious. The remaining 5% require diving deep into the internals of Ember Data. I'm tolerably good at that sort of thing, so it's a reasonable choice for me. But people who don't feel up to reading the source should probably avoid using Ember Data and stick with using jQuery to load JSON into regular Ember.Object instances (which works fine).
I haven't seen any big Angular apps first hand, but I know some former Backbone users who are diving in, and they also sound quite enthusiastic about their choice.
[deleted]
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.