Community 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.
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.
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?
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.
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.
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
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
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...
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?
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.
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.
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?
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.
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.
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.
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...
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.
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
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.
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.
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.
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.
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.
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.
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.
[+] [-] ganarajpr|13 years ago|reply
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.
[+] [-] andrew_wc_brown|13 years ago|reply
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.
[+] [-] knite|13 years ago|reply
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?
[+] [-] bsaul|13 years ago|reply
[+] [-] ganarajpr|13 years ago|reply
About the author favoring CanJS, I think you may be right.
[+] [-] dustingetz|13 years ago|reply
> 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.
[+] [-] Lazare|13 years ago|reply
[+] [-] WickyNilliams|13 years ago|reply
[+] [-] jimsteinhart|13 years ago|reply
[+] [-] landland|13 years ago|reply
[+] [-] Kiro|13 years ago|reply
[+] [-] desireco42|13 years ago|reply
I think Knockout, Batman and SpineJS which is like Backbone upgraded should be seriously considered.
Lately I use Meteor :)
[+] [-] charlysisto|13 years ago|reply
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
[+] [-] andreypopp|13 years ago|reply
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...
[+] [-] lshemesh|13 years ago|reply
[+] [-] rplnt|13 years ago|reply
[+] [-] tiedemann|13 years ago|reply
[+] [-] xsace|13 years ago|reply
[+] [-] ubersoldat2k7|13 years ago|reply
[+] [-] Kototama|13 years ago|reply
I personnaly had a bad experience with Backbone + ClojureScript because Backbone was way too much object-oriented to be meaningfull for a ClojureScript app.
[+] [-] lee|13 years ago|reply
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|13 years ago|reply
[+] [-] vovafeldman|13 years ago|reply
[+] [-] redeemedfadi|13 years ago|reply
[+] [-] st3redstripe|13 years ago|reply
[+] [-] erdogan|13 years ago|reply
[+] [-] joshontheweb|13 years ago|reply
[+] [-] tlrobinson|13 years ago|reply
[+] [-] corresation|13 years ago|reply
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.
[+] [-] ekidd|13 years ago|reply
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.
[+] [-] ganarajpr|13 years ago|reply
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.
[+] [-] gline|13 years ago|reply
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...
[+] [-] marknutter|13 years ago|reply
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..
[+] [-] davecap1|13 years ago|reply
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.
[+] [-] evilduck|13 years ago|reply
http://builtwith.angularjs.org/
[+] [-] retro212|13 years ago|reply
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.
[+] [-] ghc|13 years ago|reply
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.
[+] [-] LaSombra|13 years ago|reply
http://www.ofbrooklyn.com/2012/11/13/backbonification-migrat... and https://speakerdeck.com/samuelclay/backbonification-migratin...
[+] [-] rdtsc|13 years ago|reply
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.
[+] [-] tootie|13 years ago|reply
[+] [-] Joeri|13 years ago|reply
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.
[+] [-] numo16|13 years ago|reply
[1]: http://www.discourse.org/
[+] [-] olegp|13 years ago|reply
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.
[+] [-] harpb|13 years ago|reply
[+] [-] chauzer|13 years ago|reply
[+] [-] ulisesrmzroche|13 years ago|reply
[+] [-] porker|13 years ago|reply
[+] [-] varunkho|13 years ago|reply
[+] [-] analog|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]