7 ms·

Choosing the Right JavaScript Framework

101 points by elkelk 12y ago

prtkgpt 12y ago
AngularJS is awesome!
desaideas 12y ago
With so many js frameworks it's great to get an experts evaluation of the differences.
obiefernandez 12y ago
It seems like Backbone is dominant, but after a couple months of using AngularJS on an everyday basis I'm ready to switch and never look back. Hands-down best framework I've ever worked with. The pleasure I get from it reminds me of the early days of Rails, when the leap in productivity was palpable.
- prtkgpt 12y ago
  +1
- mikeryan 12y ago
  I've always used Backbone more as a collection of libraries and in that way its nice for lighter weight use cases and plays well with other JS code. I'm not sure if it has (or needs) enough structure to build the same sort of apps as you'd build with Angular or Ember and I've always kind of found these comparisons a bit unfair. Kind of like choosing between Sinatra and Rails.
- webjunkie01 12y ago
  I totally agree. One of the things that made me give it a try was the community support.
- capkutay 12y ago
  While Backbone's strength is its lack of assumptions and 'freeness', angular forces developers to strictly follow their constructs. Marionette [0] is an extension of backbone that also forces developers to follow constructs that lead to scalable, modular web apps. Marionette makes backbone feel like a tool to make prototypes. 0: http://marionettejs.com/ http://marionettejs.com/
  - obiefernandez 12y ago
    But how big is its community?
    - jenius 12y ago
      Marionette has a great community, and is super easy to get help with things. I've been involved in the marionette community for a while and it has always been absolutely wonderful. You can almost always get help directly from the core team on their gitter chat here (https://gitter.im/marionettejs/backbone.marionette https://gitter.im/marionettejs/backbone.marionette), and I have met in person with all of the core team members at meetups, they are very smart, dedicated and friendly. While angular has tons of beginner hype because of the bootstrap effect (don't learn a technology, just put it in your html tags!), I've found that marionette tends to attract a more mature developer crowd, and as a framework is much better suited to building large and complex apps anyway because of the strict modularity and separation of concerns. I say this from experience both seeing and working on very large and complex apps with marionette. And if you don't believe me, ask some of the developers at Etsy, who build with marionette. The community is a hell of a lot smaller than something like angular, but I see that as a huge benefit, especially when that means no proliferation of beginner problems, and easy access to the core team for help or feedback.
    - numlocked 12y ago
      Sizable enough. I never struggle to find answers to Marionette questions, and the documentation is GREAT. Plus the code is well commented at all the extensibility points. There are also three excellent books[0] about Marionette, and about 3x more Marionette questions on Stack Overflow than React questions (for what that's worth). We introduced it into our Backbone app and haven't looked back. It's great. [0]https://leanpub.com/building-backbone-plugins https://leanpub.com/building-backbone-plugins https://leanpub.com/marionette-gentle-introduction https://leanpub.com/marionette-gentle-introduction https://leanpub.com/marionette-serious-progression https://leanpub.com/marionette-serious-progression
andrewvc 12y ago
What, no React/Flux? How can this be a serious comparison without React?
- quangv 12y ago
  Yes, agreed ? I prefer it over Angular/Ember/Backbone
  - cnp 12y ago
    Far superior, far simpler, but it's not exactly a framework :/
    - kaonashi 12y ago
      Which is exactly why you should choose it.
      - swah 12y ago
        How could I do something like http://ichord.github.com/At.js http://ichord.github.com/At.js in React?
        kaonashi 12y ago
        React would handle the DOM; you would have to have some data model that handles the autocomplete list/cursor position and then feeds the results back into the react component.
      - cnp 12y ago
        Exactly :)
- capkutay 12y ago
  Flux might still be in the early adopter phase. Version 0.11 might be nice for side projects, but I'd feel uncomfortable trying to deploy a commercial app using a project that has been available to the public for less than 6 months.
carsongross 12y ago
But, but, but... what about the Un-JS Un-Framework, intercooler: http://intercoolerjs.org/ http://intercoolerjs.org/ </shameless-plug>
- dmux 12y ago
  Thanks for posting this. I have yet to get into front-end work, but this looks like the least painful way to dive in I've seen.
ld00d 12y ago
No Durandal? http://durandaljs.com/ http://durandaljs.com/
- patja 12y ago
  My reading of the roadmap is that Durandal is pretty much being absorbed into Angular 2.0
  - bronson 12y ago
    Yes, here's the announcement: http://blog.angularjs.org/2014/04/angular-and-durandal-converge.html http://blog.angularjs.org/2014/04/angular-and-durandal-conve... If it reaches anywhere near its potential it's going to be awesome.
bsaul 12y ago
Another framework i barely hear about and surprised me a bit recently is sencha/ExtJS. They're growing a lot in the enterprise sector, but they managed to keep pretty up-to-date relative to web/open sources projects such as angular.Eg they added two-way data binding in their latest version in a not-to-ugly way. Anyone here got a real try on sencha (the full package, including sencha architect) recently ?
- moriarty-s3a 12y ago
  Don't bother. It is many times larger and slower than any of the frameworks listed. Their code is also broken in "interesting" ways and there are lots of undocumented and semi-documented gotchas. It got enterprise traction because they were early to the game and promised MVC. They were pretty good for a while, but the other frameworks have passed them by.
- colinramsay 12y ago
  I'm actually writing a book on Ext JS 5 Application Architecture right now - but it's still a while off publication. In comparison to the projects mentioned in this article you're kind of looking at the difference between and framework and a library really. Compare Ext JS with something like Backbone and in addition to the way in which Backbone/Underscore helps you implement an MVC structure you've now got a whole host of UI widgets, a class/dependency system, an optional build tool in Sencha Command. The things that you'd say were feature-matches from Backbone would be stuff like Controllers (and in v5 ViewControllers), but there's a lot of stuff (like refs) to help that work with the UI components. I'd say that where ever there's an equivalent feature in Ext JS it's going to be a lot more complicated! This is a burden and a curse. Like the config system that was brought in for v4. Initially seemed like overkill, can occasionally be a godsend but when you're working on complex class structures can be a massive PITA. On top of that you have the licensing costs and indeed the licensing itself which was something that put people off of Ext JS a few years ago when they changed it. Plus I suspect "enterprise" shops will be interested in Sencha Architect too, which bumps up the cost. Sencha Command does wind me up a little bit because it feels like an opaque mess built on top of ant. I just wish they could use something like gulp and have each part be a little clearer. In fact if they opened it up to the community on github that might be enough, they're not charging for it so I don't see the harm.
Fjejfhfheifjv 12y ago
JS frameworks are absolute cancer. They do nothing but kill page load times and degrade user experience: since when is it a good idea to recompile the whole entire standard library each time a program is run? They're also completely redundant in the modern browser, since standard compliance has gotten much better and more features have been added to HTML/JS/CSS. It's just yet another api that developers have to learn to code against, despite not offering any additional features.
- themoonbus 12y ago
  I consider developer productivity and code maintainability to be features. Sure, there are performance tradeoffs, but there are some obvious benefits.
  - aikah 12y ago
    > I consider developer productivity and code maintainability to be features. Sure, there are performance tradeoffs, but there are some obvious benefits. In a client side application,if the app is slow,the users wont be happy about it. If it takes for ever to load,the users wont be happy about it. On the server there is always caching so that requests never hit the app itself. On the client,if the js code is slow ,for whatever reason,you cant hide it to the user. What you say might be true on the server,these "features" definetly have to be balanced with performances on the client.That's why sometimes it make sense to use React over AngularJS,for instance,because Angular is known to be slow.
- quaunaut 12y ago
  First time page load is heavy, yes. Then after that, it's much faster, as all the server has to hand over is JSON, which can turn a 150-500ms page load to a 15-90ms page load. Furthermore, it allows for easier data portability- when you can 'collect' data as you go and have API calls that much faster, it's okay to make more expressive UI decisions. Not to mention, at the end of the day I like having a separation between my frontend and backend. Frontend testing from Rails or Django always feels a little dirty, a little off, and in many cases is even a discouraged practice("If you need to test your view, you should be using a helper" logic). I also like not ever having to make model method choices based on what my frontend desires might be- the concerns can be completely separate. And lastly, I frankly can do a lot more interesting things much faster in Ember than I can in Rails from a UI standpoint. Ember turned my favorite part of software development, UI design, into the joy it used to be when I was just using pad and paper.
himanshuy 12y ago
No Meteor?
- KurtMueller 12y ago
  I think the author is only talking about what he knows... I hope that is the case at least. As for Meteor, I think this was a comparison of frontend-only js frameworks. I would love to see a Meteor vs. Rails vs Djano comparison however :).
grimtrigger 12y ago
If you're just getting started with frameworks, I'd recommend Backbone. You can learn it in half the time it takes to understand Angular and it'll be a good introduction to MV*. This is probably why its more popular than Angular - its easier and its good enough. Angular has a lot of "magic" which can be intimidating and frustrating. Also writing JS logic in html just feels icky when separation was the manifesto for so many years. That being said, there's many times where I work with Backbone and I feel like its missing pieces it should have. I don't have too much experience with Angular but it seems to be a much more complete choice.
- obiefernandez 12y ago
  IMO Backbone is overly complex and it's a lot harder to pervasively use data binding to templates. Didn't really feel like I realized huge productivity gains with that technique until I met Angular.
- aikah 12y ago
  > If you're just getting started with frameworks, I'd recommend Backbone. Backbone only is not enough to do any serious kind of work today.One always end up with tons of plugins making it as complicated as EmberJS or AngularJS. There is no serious view layer,so one has to use React,Vue,or Ractive. The router sucks,frankly,so one has to replace it. The model layer doesnt handle relationships between model,so one ends up using something else... There is nothing good in Backbone today frankly.It was one of the first successfull "clientside" framework ,yet refused to evolve(like underscore or coffeescript today),refused to incorporate good ideas from third parties that would have made it still relevant today. There is no future in Backbone.Maybe there is still a place for a Backbone like framework that would still be based on jQuery and would incorporate a better view layer. But Backbone itself is dead. I personally prefer AngularJS ,not because of its directives but because I strongly believe in IoC containers over any other way to build and wire objects. But I think EmberJS is as good.
  - ChrisAntaki 12y ago
    > There is nothing good in Backbone today frankly.It was one of the first successfull "clientside" framework AngularJS was released in 2009 [1], whereas Backbone was released a year later in 2010 [2]. [1] http://en.wikipedia.org/wiki/AngularJS http://en.wikipedia.org/wiki/AngularJS [2] http://en.wikipedia.org/wiki/Backbone.js http://en.wikipedia.org/wiki/Backbone.js
libria 12y ago
Enough with the "No X? http://www.X.ly" http://www.X.ly" comments. Assuming you're not spamming, submit an article yourself or talk about your framework's tradeoffs engaging points from the article above.
- ufmace 12y ago
  That's the messy thing about the JS framework ecosystem. To the outsider, it looks like there's roughly a kazillion frameworks, and it's difficult to tell what they all do, what the differences are, and how to make a reasonable decision on which one to use for a project. Post a decent comparison article like this, and you get buried in comments about how you skipped these frameworks or those plugins.
fndrplayer13 12y ago
I enjoy that the conclusion is essentially that they all have great features and pain points. I personally like Angular, but I know a number of developers successfully using Backbone.
j_s 12y ago
The previous comparison of Angular vs Ember back in May included a lot of interesting discussion, such as which companies were using which framework and a lot of anecdotes from developers with experience with both: https://news.ycombinator.com/item?id=7679116 https://news.ycombinator.com/item?id=7679116
thom_nic 12y ago
For everyone here who says "Backbone is great except..." I'd encourage you to try Apmersand.js from the great folks at &yet. It's nearly idential to Backbone, fixes some of the oddities (like wrapping divs and needing to call model.set/get) They've also worked to make it more modular and extensible. http://ampersandjs.com/ http://ampersandjs.com/
rdtsc 12y ago
To me, out of all of those, React looks most impressive and interesting.
bellerocky 12y ago
> Backbone lacks support for two-way data binding Actually Backbone is painful because of the two way data binding. You do have to write way more boiler plate, but forms and actions in views will update your models and so will content coming in from the server and your event listeners have to be able to ensure that your events don't runaway from you causing all kinds of problems. Like view action -> updates model -> listener sends something to websocket -> websocket sends a response event -> updates model -> listener sends something to websocket -> an error or infinite recursion.
- henryw 12y ago
  Rivets.js can be added to backbone fairly easily to support 2 way binding.
bsimpson 12y ago
I just did a bunch of research on state-of-the-art JS architectures for a new project I'm working on, and neither of my first two choices are on this list. (Granted, they aren't restricted to MVC either.) Polymer is interesting because it's the first one that's geared around the idea that the browser is an app rendering engine, not a document reader. Being able to declare your own HTML elements and bind them together could very well be the future of web development. Unfortunately, it's still a bit immature to use commercially. Hence, I chose React. It's idempotent, which is a fancy way of saying the markup it outputs is a strict function of the inputs it's given - no side effects, no externally-mutable state. This means you can live-edit your markup in your favorite editor without having to reload the browser on every save (using a tool called the Webpack Dev Server with the react-hot package). Using Webpack also means your dependencies are explicitly declared with `require` statements. It has all the benefits of Angular's Dependency Injector without all the boilerplate. Finally, and perhaps most importantly, it has 0 dependency on the DOM. This means you can render your initial request on the server, and pass markup down to the client that's indistinguishable from what you'd traditionally get from Flask/Django/Rails/PHP. There are no assumptions that your client speaks JavaScript, so it's more friendly to non-browser clients like searchbots, which is in turn safer for SEO. It also means your view is already rendered when it reaches the client, which is important in a world where many clients are phones with underpowered JS capabilities. You get both the benefits of a single-page-app (slow client rendering is still faster than slower network requests, and network requests are smaller if you don't have to also send down the template every time) and those of a server-side one (SEO is maintained, and the client can display your page without waiting to execute the JS first). I should disclaim that I haven't seriously considered Ember since it's been rebranded from SproutCore; however, I have worked on a few Angular apps; and even forgoing the above benefits, React is just easier to work with.
- al_the_x 12y ago
  Been meaning to look into React, so thanks for the review. Polymer is really not an option until Web Components are more broadly accepted by the browsers and better specified. One of the things I like about Angular JS is that it represents, IMO, a "baby-step" towards Web Components (which Polymer is built atop) through Directives.
acconrad 12y ago
The comments are already pretty deep, but I still want to mention that the right framework is all dependent on what your needs are and what your company is willing to support. Which is why I get tired of article comparisons like this, and trust me, I wrote an article on choosing AngularJS[1] but I still wouldn't push it on anyone. Each framework has it's advantages, and it really depends on where you and your company align with those advantages. When I started my journey I realized I needed better testing for AJAX events in jQuery, which lead me to Backbone. But in 2012 Backbone seemed like an outdated solution to an outdated app landscape. Now it seems even more outdated, but learning it certainly helped elevate my JS game to choose between Angular and Ember (though now I'd through React/Flux and/or Meteor into the mix). From there it's really about what you need, as I've said before. For me, a lightweight, performance-driven solution with a great testing framework was necessary. Angular is lighter weight than Ember, but both have great testing frameworks, so Angular won. If I wanted better documentation, an easier learning curve, or better community support (it happens that Rails people seem to like Ember because Yehuda works on it) I would have chosen Ember, but that wasn't important to me or my company. Again, that was 2012-2013, today I'm still using Angular but entertaining the idea of having React replace Angular directives, which I still don't like writing. Again, it's all about what works for you and your organization, and that really is about introspection, not about what some article can do to act as your oracle. [1] http://code.tutsplus.com/tutorials/3-reasons-to-choose-angularjs-for-your-next-project--net-28457 http://code.tutsplus.com/tutorials/3-reasons-to-choose-angul...
- fennecfoxen 12y ago
  > But in 2012 Backbone seemed like an outdated solution to an outdated app landscape Eh. Backbone is good for enabling small elements of interactivity on mostly-static web pages (a design which isn't dead yet and useful if you have a lot of people landing on a lot of individual pages from third-party sources search engines or the like, and you want to keep down page load times). Angular and Ember are much more targeted at fancy interactive web apps where you want to stay in one DOM for a longer amount of time while doing a lot of interaction or page manipulation. So this part: > the right framework is all dependent on what your needs are
al_the_x 12y ago
Great article. Really loved the "Good Parts" vs "Pain Points" for each framework.
clairity 12y ago
i appreciate the author's effort but don't feel like i have a better handle on the applicability of each framework to real projects (like many similar articles). basically, this article lists some good and bad features of each framework with some light commentary about a few of those features, which means it doesn't really help you answer the question implied by the title ("which js framework should you choose?"). i think it might be better to use a non-trivial example and show side-by-side implementations for 10 or so important aspects (routing, templating, data binding, etc.), with commentary on what kinds of projects would benefit the most from each frameworks' approach to each aspect. since airpair is about selling programming expertise, this would demonstrate actual expertise that would be attractive to prospective customers (vs. the ability to talk about programming, which is easier).
- morty16 12y ago
  There's a recent release by O'Reilly called "Choosing a Javascript Framework" (http://shop.oreilly.com/product/9781939902085.do http://shop.oreilly.com/product/9781939902085.do) that you might want to look at. It covers the same frameworks (Angular, Backbone, Ember) and also mentions Polymer and React. ~20$ for the early access version.
  - clairity 12y ago
    nice! seems a bit pricey for a rough draft ebook though. but i do like that it includes polymer and react, which i know little about. what i find interesting with these frameworks is that they're all moving the templating engine (something like coldfusion from 15 years ago, ha!) to the frontend... part of the ebb and flow of server vs client side computing i guess.
geodude 12y ago
"The scope hierarchy in Angular uses Prototypal Inheritance, which is a new concept to grasp for people coming from Object Oriented languages such as Java and C#. Failing to understand scope inheritance causes many cases of frustrated developers ..." This is javascript in general not just AnjularJS ... it seems that Google has created a framework that does a little too much. Half the time im doing something that has already been done a thousand times , either making a tab content layout, displaying a dialog , performing an ajax request and editing markup ... I dont need fancy scope for these things. And when I do ill write my own state machine. I feel like all the special AnjularJS features are built to handle stuff like google docs. Most of us dont need this, not every one is on the "kill the desktop application long live the web-app" koolaid ... And ill keep my js logic out of my view and markup, thank you very much (did we not learn this is for the lazy not the smart a long time ago)
Terr_ 12y ago
After searching the comments here too... is Dojo just too old/unsexy, or is there some sort of filtering criteria for "Javascript framework" that I'm missing?
- angersock 12y ago
  Dojo is huge and old and bloated, and has a lot of great features. Personally, I'm a bit suspicious of any JS framework more than a few years old, barring a few notable exceptions (jQuery, bootstrap, etc.). Dojo is just too large for me to feel comfortable using it in an app--with Angular or Backbone, I know there's only so much crazy in the tin; Dojo has mudballed a lot.
restlessdesign 12y ago
“Backed by Google…” Yeah, but so were Google Reader and Google Wave.
- aikah 12y ago
  Google reader wasnt open-source.As Google Wave,I believe there is an open-source version.
robot 12y ago
The article is very much inclined towards angular. I find Ember much easier to develop with due to the neat separation of application logic and HTML. In Ember, most of the logic is in the javascript, templates merely serving the final result in a presentable way. In Angular I dislike to see the angular specific programming logic molded into HTML. In my opinion HTML is just a presentation layer. An example from angular: <li ng-repeat="phone in phones | filter:query | orderBy:orderProp"> for me this is too much programming logic in html. Same goes for React.js too. Too much html + logic mixup, that requires two parsers to work in your head in parallel (html + javascript, and maybe even some css?). I find it messy. None of it in ember. Logic is neatly separated. In ember I also really enjoy how you separate functionality on a single page into neatly defined controllers/routes/ and components. Also the article says you add lots of <script> tags to your code. Not true. Using ember-cli you don't see any <script> tags.
- bsimpson 12y ago
  I've always found it weird that many people put the HTML, JS, and CSS for one component in three different files, but never thought enough about it to put it into words. Pete Hunt (one of React's maintainers) does that here: https://www.youtube.com/watch?v=DgVS-zXgMTk https://www.youtube.com/watch?v=DgVS-zXgMTk React is about separating concerns, not technologies. Everything you need to know to draw an App Bar is in AppBar.jsx. You can dynamically generate the markup with JavaScript, but that doesn't change your separation of concerns, because everything concerning that component lives in that file.
- jinushaun 12y ago
  Article seemed to have never learned to put handlebar templates in their own file, instead of including them with dozens of <script> tags.
LunaSea 12y ago
"Choosing the Right JavaScript Framework" - by someone wearing an Angular t-shirt and an Angular sticker on his laptop I'm sure it's not going to be biased at all.
rymohr 12y ago
Every few months I review the top js frameworks and always come to the same conclusion: for existing projects you're probably better off sticking with what you're already using. Each framework follows such a different paradigm that it's hard to transition incrementally, especially if you're app has a rich data layer rooted in an existing framework's mentality (in our case the backbone model/collection/sync mentality). I'd love a better view framework, but not if it requires a full rewrite of the model layer and all the related libraries. Until there's a ruby on rails quality model/collection/associations library that can be paired with a performant view framework with two-way data binding, I'll just stick with backbone where things are simple. Even if it costs me a few extra keystrokes. > A good rule of thumb is not to have more than 2,000 active bindings on the same page. Anyone personally run into this? What are you supposed to do in angular if you need to listen to change events for thousands of models?
lhorie 12y ago
If you like React for its virtual dom, but are looking for something more MVC-ish, there's also Mithril ( http://lhorie.github.io/mithril http://lhorie.github.io/mithril ). Some of the pros are that it's easy to learn (e.g. if you know js, you already know the templating language syntax), and it's one of the fastest frameworks in the market right now. There's also a more detailed comparison w/ other frameworks here: http://lhorie.github.io/mithril/comparison.html http://lhorie.github.io/mithril/comparison.html

101 points by elkelk 12y ago

prtkgpt 12y ago

AngularJS is awesome!

desaideas 12y ago

With so many js frameworks it's great to get an experts evaluation of the differences.

obiefernandez 12y ago

It seems like Backbone is dominant, but after a couple months of using AngularJS on an everyday basis I'm ready to switch and never look back. Hands-down best framework I've ever worked with. The pleasure I get from it reminds me of the early days of Rails, when the leap in productivity was palpable.

prtkgpt 12y ago
+1
mikeryan 12y ago
I've always used Backbone more as a collection of libraries and in that way its nice for lighter weight use cases and plays well with other JS code. I'm not sure if it has (or needs) enough structure to build the same sort of apps as you'd build with Angular or Ember and I've always kind of found these comparisons a bit unfair. Kind of like choosing between Sinatra and Rails.
webjunkie01 12y ago
I totally agree. One of the things that made me give it a try was the community support.
capkutay 12y ago
While Backbone's strength is its lack of assumptions and 'freeness', angular forces developers to strictly follow their constructs. Marionette [0] is an extension of backbone that also forces developers to follow constructs that lead to scalable, modular web apps. Marionette makes backbone feel like a tool to make prototypes. 0: http://marionettejs.com/ http://marionettejs.com/
- obiefernandez 12y ago
  But how big is its community?
  - jenius 12y ago
    Marionette has a great community, and is super easy to get help with things. I've been involved in the marionette community for a while and it has always been absolutely wonderful. You can almost always get help directly from the core team on their gitter chat here (https://gitter.im/marionettejs/backbone.marionette https://gitter.im/marionettejs/backbone.marionette), and I have met in person with all of the core team members at meetups, they are very smart, dedicated and friendly. While angular has tons of beginner hype because of the bootstrap effect (don't learn a technology, just put it in your html tags!), I've found that marionette tends to attract a more mature developer crowd, and as a framework is much better suited to building large and complex apps anyway because of the strict modularity and separation of concerns. I say this from experience both seeing and working on very large and complex apps with marionette. And if you don't believe me, ask some of the developers at Etsy, who build with marionette. The community is a hell of a lot smaller than something like angular, but I see that as a huge benefit, especially when that means no proliferation of beginner problems, and easy access to the core team for help or feedback.
  - numlocked 12y ago
    Sizable enough. I never struggle to find answers to Marionette questions, and the documentation is GREAT. Plus the code is well commented at all the extensibility points. There are also three excellent books[0] about Marionette, and about 3x more Marionette questions on Stack Overflow than React questions (for what that's worth). We introduced it into our Backbone app and haven't looked back. It's great. [0]https://leanpub.com/building-backbone-plugins https://leanpub.com/building-backbone-plugins https://leanpub.com/marionette-gentle-introduction https://leanpub.com/marionette-gentle-introduction https://leanpub.com/marionette-serious-progression https://leanpub.com/marionette-serious-progression

andrewvc 12y ago

What, no React/Flux? How can this be a serious comparison without React?

quangv 12y ago
Yes, agreed ? I prefer it over Angular/Ember/Backbone
- cnp 12y ago
  Far superior, far simpler, but it's not exactly a framework :/
  - kaonashi 12y ago
    Which is exactly why you should choose it.
    - swah 12y ago
      How could I do something like http://ichord.github.com/At.js http://ichord.github.com/At.js in React?
      - kaonashi 12y ago
        React would handle the DOM; you would have to have some data model that handles the autocomplete list/cursor position and then feeds the results back into the react component.
    - cnp 12y ago
      Exactly :)
capkutay 12y ago
Flux might still be in the early adopter phase. Version 0.11 might be nice for side projects, but I'd feel uncomfortable trying to deploy a commercial app using a project that has been available to the public for less than 6 months.

carsongross 12y ago

But, but, but... what about the Un-JS Un-Framework, intercooler: http://intercoolerjs.org/ http://intercoolerjs.org/ </shameless-plug>

dmux 12y ago
Thanks for posting this. I have yet to get into front-end work, but this looks like the least painful way to dive in I've seen.

ld00d 12y ago

No Durandal? http://durandaljs.com/ http://durandaljs.com/

patja 12y ago
My reading of the roadmap is that Durandal is pretty much being absorbed into Angular 2.0
- bronson 12y ago
  Yes, here's the announcement: http://blog.angularjs.org/2014/04/angular-and-durandal-converge.html http://blog.angularjs.org/2014/04/angular-and-durandal-conve... If it reaches anywhere near its potential it's going to be awesome.

bsaul 12y ago

Another framework i barely hear about and surprised me a bit recently is sencha/ExtJS. They're growing a lot in the enterprise sector, but they managed to keep pretty up-to-date relative to web/open sources projects such as angular.Eg they added two-way data binding in their latest version in a not-to-ugly way. Anyone here got a real try on sencha (the full package, including sencha architect) recently ?

moriarty-s3a 12y ago
Don't bother. It is many times larger and slower than any of the frameworks listed. Their code is also broken in "interesting" ways and there are lots of undocumented and semi-documented gotchas. It got enterprise traction because they were early to the game and promised MVC. They were pretty good for a while, but the other frameworks have passed them by.
colinramsay 12y ago
I'm actually writing a book on Ext JS 5 Application Architecture right now - but it's still a while off publication. In comparison to the projects mentioned in this article you're kind of looking at the difference between and framework and a library really. Compare Ext JS with something like Backbone and in addition to the way in which Backbone/Underscore helps you implement an MVC structure you've now got a whole host of UI widgets, a class/dependency system, an optional build tool in Sencha Command. The things that you'd say were feature-matches from Backbone would be stuff like Controllers (and in v5 ViewControllers), but there's a lot of stuff (like refs) to help that work with the UI components. I'd say that where ever there's an equivalent feature in Ext JS it's going to be a lot more complicated! This is a burden and a curse. Like the config system that was brought in for v4. Initially seemed like overkill, can occasionally be a godsend but when you're working on complex class structures can be a massive PITA. On top of that you have the licensing costs and indeed the licensing itself which was something that put people off of Ext JS a few years ago when they changed it. Plus I suspect "enterprise" shops will be interested in Sencha Architect too, which bumps up the cost. Sencha Command does wind me up a little bit because it feels like an opaque mess built on top of ant. I just wish they could use something like gulp and have each part be a little clearer. In fact if they opened it up to the community on github that might be enough, they're not charging for it so I don't see the harm.

Fjejfhfheifjv 12y ago

JS frameworks are absolute cancer. They do nothing but kill page load times and degrade user experience: since when is it a good idea to recompile the whole entire standard library each time a program is run? They're also completely redundant in the modern browser, since standard compliance has gotten much better and more features have been added to HTML/JS/CSS. It's just yet another api that developers have to learn to code against, despite not offering any additional features.

themoonbus 12y ago
I consider developer productivity and code maintainability to be features. Sure, there are performance tradeoffs, but there are some obvious benefits.
- aikah 12y ago
  > I consider developer productivity and code maintainability to be features. Sure, there are performance tradeoffs, but there are some obvious benefits. In a client side application,if the app is slow,the users wont be happy about it. If it takes for ever to load,the users wont be happy about it. On the server there is always caching so that requests never hit the app itself. On the client,if the js code is slow ,for whatever reason,you cant hide it to the user. What you say might be true on the server,these "features" definetly have to be balanced with performances on the client.That's why sometimes it make sense to use React over AngularJS,for instance,because Angular is known to be slow.
quaunaut 12y ago
First time page load is heavy, yes. Then after that, it's much faster, as all the server has to hand over is JSON, which can turn a 150-500ms page load to a 15-90ms page load. Furthermore, it allows for easier data portability- when you can 'collect' data as you go and have API calls that much faster, it's okay to make more expressive UI decisions. Not to mention, at the end of the day I like having a separation between my frontend and backend. Frontend testing from Rails or Django always feels a little dirty, a little off, and in many cases is even a discouraged practice("If you need to test your view, you should be using a helper" logic). I also like not ever having to make model method choices based on what my frontend desires might be- the concerns can be completely separate. And lastly, I frankly can do a lot more interesting things much faster in Ember than I can in Rails from a UI standpoint. Ember turned my favorite part of software development, UI design, into the joy it used to be when I was just using pad and paper.

himanshuy 12y ago

No Meteor?

KurtMueller 12y ago
I think the author is only talking about what he knows... I hope that is the case at least. As for Meteor, I think this was a comparison of frontend-only js frameworks. I would love to see a Meteor vs. Rails vs Djano comparison however :).

grimtrigger 12y ago

If you're just getting started with frameworks, I'd recommend Backbone. You can learn it in half the time it takes to understand Angular and it'll be a good introduction to MV*. This is probably why its more popular than Angular - its easier and its good enough. Angular has a lot of "magic" which can be intimidating and frustrating. Also writing JS logic in html just feels icky when separation was the manifesto for so many years. That being said, there's many times where I work with Backbone and I feel like its missing pieces it should have. I don't have too much experience with Angular but it seems to be a much more complete choice.

obiefernandez 12y ago
IMO Backbone is overly complex and it's a lot harder to pervasively use data binding to templates. Didn't really feel like I realized huge productivity gains with that technique until I met Angular.
aikah 12y ago
> If you're just getting started with frameworks, I'd recommend Backbone. Backbone only is not enough to do any serious kind of work today.One always end up with tons of plugins making it as complicated as EmberJS or AngularJS. There is no serious view layer,so one has to use React,Vue,or Ractive. The router sucks,frankly,so one has to replace it. The model layer doesnt handle relationships between model,so one ends up using something else... There is nothing good in Backbone today frankly.It was one of the first successfull "clientside" framework ,yet refused to evolve(like underscore or coffeescript today),refused to incorporate good ideas from third parties that would have made it still relevant today. There is no future in Backbone.Maybe there is still a place for a Backbone like framework that would still be based on jQuery and would incorporate a better view layer. But Backbone itself is dead. I personally prefer AngularJS ,not because of its directives but because I strongly believe in IoC containers over any other way to build and wire objects. But I think EmberJS is as good.
- ChrisAntaki 12y ago
  > There is nothing good in Backbone today frankly.It was one of the first successfull "clientside" framework AngularJS was released in 2009 [1], whereas Backbone was released a year later in 2010 [2]. [1] http://en.wikipedia.org/wiki/AngularJS http://en.wikipedia.org/wiki/AngularJS [2] http://en.wikipedia.org/wiki/Backbone.js http://en.wikipedia.org/wiki/Backbone.js

libria 12y ago

Enough with the "No X? http://www.X.ly" http://www.X.ly" comments. Assuming you're not spamming, submit an article yourself or talk about your framework's tradeoffs engaging points from the article above.

ufmace 12y ago
That's the messy thing about the JS framework ecosystem. To the outsider, it looks like there's roughly a kazillion frameworks, and it's difficult to tell what they all do, what the differences are, and how to make a reasonable decision on which one to use for a project. Post a decent comparison article like this, and you get buried in comments about how you skipped these frameworks or those plugins.

fndrplayer13 12y ago

I enjoy that the conclusion is essentially that they all have great features and pain points. I personally like Angular, but I know a number of developers successfully using Backbone.

j_s 12y ago

The previous comparison of Angular vs Ember back in May included a lot of interesting discussion, such as which companies were using which framework and a lot of anecdotes from developers with experience with both: https://news.ycombinator.com/item?id=7679116 https://news.ycombinator.com/item?id=7679116

thom_nic 12y ago

For everyone here who says "Backbone is great except..." I'd encourage you to try Apmersand.js from the great folks at &yet. It's nearly idential to Backbone, fixes some of the oddities (like wrapping divs and needing to call model.set/get) They've also worked to make it more modular and extensible. http://ampersandjs.com/ http://ampersandjs.com/

rdtsc 12y ago

To me, out of all of those, React looks most impressive and interesting.

bellerocky 12y ago

> Backbone lacks support for two-way data binding Actually Backbone is painful because of the two way data binding. You do have to write way more boiler plate, but forms and actions in views will update your models and so will content coming in from the server and your event listeners have to be able to ensure that your events don't runaway from you causing all kinds of problems. Like view action -> updates model -> listener sends something to websocket -> websocket sends a response event -> updates model -> listener sends something to websocket -> an error or infinite recursion.

henryw 12y ago
Rivets.js can be added to backbone fairly easily to support 2 way binding.

bsimpson 12y ago

I just did a bunch of research on state-of-the-art JS architectures for a new project I'm working on, and neither of my first two choices are on this list. (Granted, they aren't restricted to MVC either.) Polymer is interesting because it's the first one that's geared around the idea that the browser is an app rendering engine, not a document reader. Being able to declare your own HTML elements and bind them together could very well be the future of web development. Unfortunately, it's still a bit immature to use commercially. Hence, I chose React. It's idempotent, which is a fancy way of saying the markup it outputs is a strict function of the inputs it's given - no side effects, no externally-mutable state. This means you can live-edit your markup in your favorite editor without having to reload the browser on every save (using a tool called the Webpack Dev Server with the react-hot package). Using Webpack also means your dependencies are explicitly declared with `require` statements. It has all the benefits of Angular's Dependency Injector without all the boilerplate. Finally, and perhaps most importantly, it has 0 dependency on the DOM. This means you can render your initial request on the server, and pass markup down to the client that's indistinguishable from what you'd traditionally get from Flask/Django/Rails/PHP. There are no assumptions that your client speaks JavaScript, so it's more friendly to non-browser clients like searchbots, which is in turn safer for SEO. It also means your view is already rendered when it reaches the client, which is important in a world where many clients are phones with underpowered JS capabilities. You get both the benefits of a single-page-app (slow client rendering is still faster than slower network requests, and network requests are smaller if you don't have to also send down the template every time) and those of a server-side one (SEO is maintained, and the client can display your page without waiting to execute the JS first). I should disclaim that I haven't seriously considered Ember since it's been rebranded from SproutCore; however, I have worked on a few Angular apps; and even forgoing the above benefits, React is just easier to work with.

al_the_x 12y ago
Been meaning to look into React, so thanks for the review. Polymer is really not an option until Web Components are more broadly accepted by the browsers and better specified. One of the things I like about Angular JS is that it represents, IMO, a "baby-step" towards Web Components (which Polymer is built atop) through Directives.

acconrad 12y ago

The comments are already pretty deep, but I still want to mention that the right framework is all dependent on what your needs are and what your company is willing to support. Which is why I get tired of article comparisons like this, and trust me, I wrote an article on choosing AngularJS[1] but I still wouldn't push it on anyone. Each framework has it's advantages, and it really depends on where you and your company align with those advantages. When I started my journey I realized I needed better testing for AJAX events in jQuery, which lead me to Backbone. But in 2012 Backbone seemed like an outdated solution to an outdated app landscape. Now it seems even more outdated, but learning it certainly helped elevate my JS game to choose between Angular and Ember (though now I'd through React/Flux and/or Meteor into the mix). From there it's really about what you need, as I've said before. For me, a lightweight, performance-driven solution with a great testing framework was necessary. Angular is lighter weight than Ember, but both have great testing frameworks, so Angular won. If I wanted better documentation, an easier learning curve, or better community support (it happens that Rails people seem to like Ember because Yehuda works on it) I would have chosen Ember, but that wasn't important to me or my company. Again, that was 2012-2013, today I'm still using Angular but entertaining the idea of having React replace Angular directives, which I still don't like writing. Again, it's all about what works for you and your organization, and that really is about introspection, not about what some article can do to act as your oracle. [1] http://code.tutsplus.com/tutorials/3-reasons-to-choose-angularjs-for-your-next-project--net-28457 http://code.tutsplus.com/tutorials/3-reasons-to-choose-angul...

fennecfoxen 12y ago
> But in 2012 Backbone seemed like an outdated solution to an outdated app landscape Eh. Backbone is good for enabling small elements of interactivity on mostly-static web pages (a design which isn't dead yet and useful if you have a lot of people landing on a lot of individual pages from third-party sources search engines or the like, and you want to keep down page load times). Angular and Ember are much more targeted at fancy interactive web apps where you want to stay in one DOM for a longer amount of time while doing a lot of interaction or page manipulation. So this part: > the right framework is all dependent on what your needs are

al_the_x 12y ago

Great article. Really loved the "Good Parts" vs "Pain Points" for each framework.

clairity 12y ago

i appreciate the author's effort but don't feel like i have a better handle on the applicability of each framework to real projects (like many similar articles). basically, this article lists some good and bad features of each framework with some light commentary about a few of those features, which means it doesn't really help you answer the question implied by the title ("which js framework should you choose?"). i think it might be better to use a non-trivial example and show side-by-side implementations for 10 or so important aspects (routing, templating, data binding, etc.), with commentary on what kinds of projects would benefit the most from each frameworks' approach to each aspect. since airpair is about selling programming expertise, this would demonstrate actual expertise that would be attractive to prospective customers (vs. the ability to talk about programming, which is easier).

morty16 12y ago
There's a recent release by O'Reilly called "Choosing a Javascript Framework" (http://shop.oreilly.com/product/9781939902085.do http://shop.oreilly.com/product/9781939902085.do) that you might want to look at. It covers the same frameworks (Angular, Backbone, Ember) and also mentions Polymer and React. ~20$ for the early access version.
- clairity 12y ago
  nice! seems a bit pricey for a rough draft ebook though. but i do like that it includes polymer and react, which i know little about. what i find interesting with these frameworks is that they're all moving the templating engine (something like coldfusion from 15 years ago, ha!) to the frontend... part of the ebb and flow of server vs client side computing i guess.

geodude 12y ago

"The scope hierarchy in Angular uses Prototypal Inheritance, which is a new concept to grasp for people coming from Object Oriented languages such as Java and C#. Failing to understand scope inheritance causes many cases of frustrated developers ..." This is javascript in general not just AnjularJS ... it seems that Google has created a framework that does a little too much. Half the time im doing something that has already been done a thousand times , either making a tab content layout, displaying a dialog , performing an ajax request and editing markup ... I dont need fancy scope for these things. And when I do ill write my own state machine. I feel like all the special AnjularJS features are built to handle stuff like google docs. Most of us dont need this, not every one is on the "kill the desktop application long live the web-app" koolaid ... And ill keep my js logic out of my view and markup, thank you very much (did we not learn this is for the lazy not the smart a long time ago)

Terr_ 12y ago

After searching the comments here too... is Dojo just too old/unsexy, or is there some sort of filtering criteria for "Javascript framework" that I'm missing?

angersock 12y ago
Dojo is huge and old and bloated, and has a lot of great features. Personally, I'm a bit suspicious of any JS framework more than a few years old, barring a few notable exceptions (jQuery, bootstrap, etc.). Dojo is just too large for me to feel comfortable using it in an app--with Angular or Backbone, I know there's only so much crazy in the tin; Dojo has mudballed a lot.

restlessdesign 12y ago

“Backed by Google…” Yeah, but so were Google Reader and Google Wave.

aikah 12y ago
Google reader wasnt open-source.As Google Wave,I believe there is an open-source version.

robot 12y ago

The article is very much inclined towards angular. I find Ember much easier to develop with due to the neat separation of application logic and HTML. In Ember, most of the logic is in the javascript, templates merely serving the final result in a presentable way. In Angular I dislike to see the angular specific programming logic molded into HTML. In my opinion HTML is just a presentation layer. An example from angular: <li ng-repeat="phone in phones | filter:query | orderBy:orderProp"> for me this is too much programming logic in html. Same goes for React.js too. Too much html + logic mixup, that requires two parsers to work in your head in parallel (html + javascript, and maybe even some css?). I find it messy. None of it in ember. Logic is neatly separated. In ember I also really enjoy how you separate functionality on a single page into neatly defined controllers/routes/ and components. Also the article says you add lots of <script> tags to your code. Not true. Using ember-cli you don't see any <script> tags.

bsimpson 12y ago
I've always found it weird that many people put the HTML, JS, and CSS for one component in three different files, but never thought enough about it to put it into words. Pete Hunt (one of React's maintainers) does that here: https://www.youtube.com/watch?v=DgVS-zXgMTk https://www.youtube.com/watch?v=DgVS-zXgMTk React is about separating concerns, not technologies. Everything you need to know to draw an App Bar is in AppBar.jsx. You can dynamically generate the markup with JavaScript, but that doesn't change your separation of concerns, because everything concerning that component lives in that file.
jinushaun 12y ago
Article seemed to have never learned to put handlebar templates in their own file, instead of including them with dozens of <script> tags.

LunaSea 12y ago

"Choosing the Right JavaScript Framework" - by someone wearing an Angular t-shirt and an Angular sticker on his laptop I'm sure it's not going to be biased at all.

rymohr 12y ago

Every few months I review the top js frameworks and always come to the same conclusion: for existing projects you're probably better off sticking with what you're already using. Each framework follows such a different paradigm that it's hard to transition incrementally, especially if you're app has a rich data layer rooted in an existing framework's mentality (in our case the backbone model/collection/sync mentality). I'd love a better view framework, but not if it requires a full rewrite of the model layer and all the related libraries. Until there's a ruby on rails quality model/collection/associations library that can be paired with a performant view framework with two-way data binding, I'll just stick with backbone where things are simple. Even if it costs me a few extra keystrokes. > A good rule of thumb is not to have more than 2,000 active bindings on the same page. Anyone personally run into this? What are you supposed to do in angular if you need to listen to change events for thousands of models?

lhorie 12y ago

If you like React for its virtual dom, but are looking for something more MVC-ish, there's also Mithril ( http://lhorie.github.io/mithril http://lhorie.github.io/mithril ). Some of the pros are that it's easy to learn (e.g. if you know js, you already know the templating language syntax), and it's one of the fastest frameworks in the market right now. There's also a more detailed comparison w/ other frameworks here: http://lhorie.github.io/mithril/comparison.html http://lhorie.github.io/mithril/comparison.html