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.
The thing that I don't like about web components is that it's a browser specific technology. With React, I can render the first page on the server, so the user doesn't have to wait 3 seconds for the initial page load. So I'm not a huge fan of anything that's browser specific and can't be rendered on the server. I see why Google is pushing for it - web components would mean crawlers not having to execute Javascript, which translates to significant savings on crawling infrastructure. But it'd make for a shitty user experience.
>There are no assumptions that your client speaks JavaScript, so it's more friendly to non-browser clients like searchbots
Thanks for pointing this out, I'm always glad to see people taking responsibility for the quality of their contributions to the web and finding tools that enable good work.
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.
React is also elemental, but in a different sort of way. Your elements effectively become substitutions:
// When I say
<IconButton
link-to = "home"
src = "home.svg
/>
// give me
<a
class = "IconButton"
href = "/"
>
<img src = "home.svg" />
</a>
It doesn't show up as custom elements in the DOM (hence you have to manually specify the class name in your substitution). It's also idempotent, so no fancy data binding. Otherwise, same idea.
Are there any real world combinations of real time frameworks like Derby, Meteor, SocketStream, Mojito, or even Firebase+MVC with a pre-rendering engine like Polymer or Famo.us?
>This means you can render your initial request on the server, and pass markup down to the client
famo.us is shockingly bad IMHO. It breaks many common user interactions and goes through a load of hoops to enable "native performance" and then doesn't even get that right, I really don't understand the hype.
If you don't mind sharing, have you done any research on data layers for React? From what I can see, there seems to be three major schools of thought: the Flux architecture, using Backbone's models, or just writing something custom.
Still working on the data layer, but I think I'm going to use Reflux. One of the things I was initially skeptical of React about is its lack of support for custom event bubbling (which is the technique I like to use to keep my components decoupled).
Flux lets you cheat around that: Since you're using require statements, you can make an action and `require()` it in both the component it's dispatched from and the one that's listening to it.
The store is an extra layer of abstraction, so you can assimilate data from different sources (user interaction, server events, etc) into one format before passing them into your datastream. Facebook's Flux has yet another layer of abstraction called the Dispatcher.
Honestly, I'm murky on the utility of the Store and even less confident in the utility of the Dispatcher. That's why I'm using Reflux instead of FBFlux, and I'm still tempted to skip the store and just listen to my actions from the parent component.
I'm currently using Fluxxor[1] which reifies the Flux architecture with Stores and a central dispatcher. I did some research into Backbone.Model bindings but eventually decided to go "full Flux". I've yet to regret my decision even though my app has grown quite complex.
The best part is, thanks to React & Flux I'm building a large scale web app without jQuery for the first time in my life :)
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.
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.
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:
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.
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.
> 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.
> 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*.
Backbone is easier to learn, agreed. I would recommend checking out a list of sites built with Angular & Backbone too.
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.
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 ).
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 no standards, but at this point I'd say Flux + React-router are quickly becoming it. react-router is made in the spirit of Ember's which is pretty well liked.
- Flux Architecture Pattern [0]
- React Router [1]
Note that there isn't really a prescribed model in Angular aside from $scope either.
I like react-router that looks quite nice. Flux looks like a description of an idea rather a JavaScript library. Is there a flux store that persists to a REST backend?
A model really isn't part of Angular core since it was split out but something like angular-resource is what I am talking about.
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.
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.
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 ?
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.
I've worked on two big projects using ExtJS and both of them were/are nightmares: the code is complicated, tied very deeply to the ExtJS infrastructure, if there's a bug you wait on Sencha and you are probably going to have to pay for an expensive consultant at some point.
Now, I'm pretty negative on client-side MVC anyway (see intercooler.js) so I'm probably not a fair judge, but if I were starting a project today that had to have a large client-side footprint, I'd avoid ExtJS.
I will say that ExtJS looks great OOTB and comes with a ton of widget functionality when compared with other options, so if you want to get something done really quickly with, say, a tree UI, that might be a reason to look at them harder.
I've been developing on the sencha products for years. Primarily an ExtJS single page app developed by a large team since 2008 that's now well on its way to 200.000 lines of code. I also wrote a 5 kloc app in sencha touch.
The thing about sencha that makes them different is that they abstract away the html and css parts to a large degree, by constructing the dom programmatically behind an abstracted component api (e.g., a panel component has a title bar, several toolbars, and multiple child components laid out using border, anchor, column or any of the other layout systems). The upside is that the ui controls are richer than standard html controls and require fewer lines to do advanced things (like having a field with server-backed autocomplete). The downside is that html+css skills don't translate well, if at all. Instead of thinking in terms of dom updates, html templates and style rules, you think in terms of the component lifecycle, the container layout system and themes. The skillset required is extensive and specific, and the code is so deeply tied to extjs that no part of it can be reused outside of it.
Some people like it, some people don't. You can't fight the framework. You have to adopt sencha's architecture and component system completely, or you will have a painful time. We have had to invest extensively in training because the framework is so different from other js frameworks that new developers have a hard time learning it.
As for the whole she-bang, sencha cmd, sencha architect and so on. I tried those tools several times, but they always lacked maturity. The last time i looked at it is 2 years ago though, so they may have improved. Meanwhile we just use the frameworks.
Update: I realized I didn't actually say whether I would recommend it or not. I would not choose ExtJS again, but I would choose sencha touch again, despite the API's being so similar. I feel like the use-case of writing a mobile cross-platform app fits in well with the sencha architecture and api, better than other js frameworks. By contrast ExtJS isn't bad, but it's no better than the free alternatives like ember or angular for building traditional web apps, so I don't see the point in spending the money on a license if you're starting from scratch.
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.
I develop with Sencha frameworks full time. The learning curve is on the same level as Ember, while not easy but still manageable, unlike many people want you to believe.
ExtJS component life cycle changed a lot form 4.0 to 4.2 and they refactored the code to be more like Sencha Touch. I guess this is the preamble to ExtJS 5, and it confuses a lot of people.
Sencha delivers on cross browser compatibility, since their layouts are all done by JavaScript. Trying to add CSS layout on top of that will break a lot of things. This is the so called "fighting the framework" people in Sencha community calls it. ExtJS 5 lets you develop desktop/touch hybrid apps for touch laptops. With smooth scrolling driven by touch event and transition, they work on Android as well (where it doesn't have WebKit overflow scroll touch)
I do ExtJS allll-daaay long, because my company built every back-office we made upon that framework.
Pro: It looks and feels like a desktop application. B2B loves that! (And that's why we use it)
Cons: It requires you to write gigantic blocks of code to get something up and running. + Many times you will say to yourself "they can't have forgotten THAT feature", and well, they did and you have to DIY
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.
> 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
I would absolutely not use Backbone for anything view related anymore. React.js is a much better choice, even for just enabling small islands of richness.
"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)
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?
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.
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.
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), 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.
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.
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.
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.
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).
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.
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:
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.
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.
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?
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.
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.
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.
You can't get around needing to do some DOM manipulation via javascript, and Angular completely reduces the amount of code necessary to perform common user interactions. I've coded the jQuery way forever, and as a developer I quickly fell in love with Angular. That being said, it really depends on your needs for you application whether or not to implement a framework.
> 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.
wow , is this the ... show HN hyperbole thread??? ...
they do something ... thats why they slow down the page ... but you know the page wouldnt even be there if you didnt have a tool to speed up your development ... I hope you have fun with your css transitions call me when you want some two way data binding with ajax calls ... I think I know some tools that help do that :>
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.