Perhaps you’ve had a chance to experiment with one or two of these frameworks, but are still a little unsure about the best one to commit to mastering. Web development, particularly front-end development, has been moving at a blistering pace and there is constant pressure to add valuable new skills to your repertoire.
Developers have to make tough choices about what they are going to focus on, and the idea of spending months learning a new framework that ultimately doesn’t pay off isn’t very appealing, not to mention if the result is a production application you are then committed to maintaining.
What follows is a high level look at these frameworks. It’s the result of my experience with them over the past couple of years. Some of them I’ve dug into more deeply than others, but I tried to understand the benefits and concerns with each so that I could make an informed choice about which has the most to offer.
The View from 35,000 Feet
Before we discuss the individual frameworks, let’s take a moment to get a handle on the big picture. Why would we want to use one of these frameworks in the first place? Why not just stick with a traditional server-side application?
Of course, you can do similar things with a traditional app and a bit of jQuery, but if you’ve ever tried that then you know how quickly you can run into trouble. Unless you’re dealing with something simple, code management with jQuery quickly becomes a challenge, often leading to “spaghetti” code.
Now that we have a general idea of why these frameworks are getting so much attention, let’s look at each of them in turn and see what they have to offer.
First released in 2010 by Jeremy Ashkenas, Backbone is lightweight. Coming in at just 6.3KB when minified and compressed for production and with only one dependency (Underscore.js), it’s a highly versatile and minimalistic MVC (Model-View-Controller) framework that powers a lot of sites you may be familiar with: Twitter, Hulu, Pinterest and my personal favorite, Pandora Radio.
Aside from the compact file size, Backbone’s great strength is its versatility. Unlike the other frameworks, Backbone isn’t highly opinionated. For example, it doesn’t come with it’s own templating engine (aside from the basic one included in Underscore), leaving developers to choose whatever works best for them on a given project.
Because it’s so lightweight, Backbone shines brightest when used in simpler projects where speed is a priority - think single page apps (Twitter, Pinterest) or a widget that is part of a traditional web application.
There are also concerns about the need for excessive “boilerplate” code in order to use the framework successfully in a project. These complaints are often dismissed by more experienced developers who suggest those who are writing a lot of boilerplate on each project aren’t using Backbone correctly.
Another significant concern—not unique to Backbone by any means—is a lack of server-side rendering. For a more in-depth discussion of this, I recommend reading Tim Kadlec’s excellent post on the topic. He writes, “if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.”
Backbone is a framework that shines brightest in the hands of experienced developers building single page applications (SPAs) and widgets. If you’re interested in using it beyond that scope, be sure to look into options for server-side rendering and do research on additional libraries and plugins you may need in order to build your application.
It may surprise you to learn that AngularJS is actually an older framework than Backbone, first released in 2009 by Brat Tech LLC. But the reason Angular is typically seen as the more recent entry in the field is that it didn’t take off until it came under Google’s patronage. A quick look at Google Trends show Angular (the red line in the graph below) gaining traction in early 2012 and exploding in popularity over the next few years.
Of course this graph doesn’t tell the whole story of the relative popularity of these frameworks (it greatly undercounts React, for example), but it does give an idea of the level of attention Angular has received. This prominence has led to a robust community of contributors, but also a lot of pointed criticism that Angular fails to live up to the hype surrounding it.
Coming in at 36KB when minified and zipped for production, Angular is often called a Model-View-Whatever framework because it doesn’t adhere to the typical MVC design pattern. It’s beefier than Backbone, but you also get a lot more built-in functionality, as we’ll see below. Some notable sites built with AngularJS include: VEVO, The Weather Channel and MSNBC.
Two-way data binding is a much loved feature of AngularJS that describes the condition where data is bound to an HTML element in the View and that element has the ability to both update and display that data. In Angular, both the Model and the View can update the data, thus the “two-way” descriptor. Angular’s implementation of this form of data binding allows for a reduction in the amount of code required to create dynamic views.
Another popular feature is directives, which allow developers to extend HTML by attaching special behaviors to parts of the DOM. For example, ng-repeat is a directive that allows developers to repeat an element, making it very handy for doing things like printing an array of items to the page. In addition to the directives that come with Angular, you can create your own, allowing for a great deal of flexibility in crafting behaviors for the UI.
Dependency injection is another great feature of Angular that allows developers to easily include services in their modules. For example, if a developer is writing a function and wants to use the $location service (a service that parses the URL in the browser address bar), all that’s required is to include it as a parameter of the function and Angular will make sure that an instance of that service is available to that function. This is also useful for injecting mock data into components which is a feature that helps make Angular highly testable.
Finally, having Google as a sponsor helps. Many enterprises (and developers) have taken the plunge on Angular because they have seen Google’s involvement as a proxy for stability, which is often a critical consideration.
Two-way data binding! Yes, two-way data binding makes both the list of benefits and concerns. Although it does make it easier to build with Angular, people have criticized the two-way data binding because it complicates debugging and hurts performance.
Also of concern, the upcoming Angular 2 will be a complete rewrite of the framework—no backwards compatibility. Many see this as a tacit acknowledgement on the part of the Angular team that the initial approach was flawed. It also may have undermined the perceived stability of the project among enterprises.
For a very useful and informative critique of Angular, I recommend this post by Peter-Paul Koch. It provides a lot of context and detailed analysis that is outside the scope of our present discussion.
One final note, Angular, like Backbone, lacks server-side rendering, though workarounds exist.
Angular works in a wide range of use cases from small projects to enterprise applications. Nevertheless, if you’re planning a large, complex application, having skilled developers on hand who can tackle any performance issues that arise, is critical.
Given the transition from version 1 to version 2, Angular doesn’t seem like a great choice at this point in time. Learning the current version of Angular may only position a developer to work on legacy applications and still require learning the upcoming version as well. Tall order! Whether it will be a good choice to take up Angular 2 remains to be seen.
Ember bills itself as, “A framework for creating ambitious web applications”, and it has an interesting pedigree. It was created in late 2011 by Yehuda Katz, who is also a member of the jQuery and Ruby on Rails core teams.
Just as AngularJS feels like a framework written by Java developers (because it was), Ember is often said to be reminiscent of Rails, no doubt due to Katz’ intimacy with that project.
Ember, quite proudly, does not have a corporate sponsor. It is built by a robust community of developers “scratching their own itch”.
Coming in at 95KB minified and compressed for production, it is one of the heftiest of the four frameworks under discussion (jQuery and Handlebars are required dependencies that will add to that total). But with the extra size, you get a lot of built-in functionality. Websites built with Ember include: Qualcomm, Chicago.com, Nest, Vine and NBC News.
There is a general principle within the Ember community: “convention over configuration”. When working with Ember, you should do things the “Ember way”. Pretty much everything you need to write a web app is built-in, including a templating library, routing, and tons of other things that are intended to free developers from routine and mundane reinvent-the-wheel tasks, allowing them to focus on the larger problems that are unique to their project.
One interesting thing about Ember is the Ember CLI. Although it’s not required in order to work with Ember, it’s a useful command line tool that handles a lot of things people commonly use Grunt or Gulp to do—compile Sass and minify CSS and JS, for example. Maybe you don’t want to mess with your current build system, but if you don’t have one in place, this is a tool that can get you started with minimal hassle.
The other thing that many developers seem to love about Ember is the fact that it doesn’t have a corporate patron and that the team behind it is deeply committed to open source software. There are some developers who look at the corporate sponsorship of other frameworks a bit warily, so this commitment from the Ember team will be a factor for those folks.
The biggest concern with Ember is the need to do things the “Ember way”. Now, to some extent, this is similar to Angular, but Ember takes it further. Ember aspires to provide a complete solution, soup to nuts. It’s certainly a marked contrast with Backbone that allows you to mix and match things more or less as you see fit.
There is also a lot of generated code with this approach that can lead to difficulty with developers understanding exactly what’s going on. When you have a large framework, with so much built-in functionality, the learning curve is steep.
Ember also uses two-way data binding, although it uses a different implementation than Angular. Perhaps in response to community concerns, the Ember team has announced they will be moving away from two-way data binding in the future.
Ember is a good framework and in areas of weakness, there seems to be a lot of effort to improve. For example, like Angular and Backbone, it doesn’t support server-side rendering, but it has been announced that it will have that support soon, which is great. Overall, I think Ember may be best suited for teams working on medium to large projects. It is highly opinionated, so if you like to roll your own, it may not be for you.
The new kid on the block is also currently the hottest, stealing much of Angular’s buzz. Released in 2013 by Facebook, it takes a different approach from the other frameworks we’ve been discussing.
Backbone, Angular and Ember are often referred to as client-side MVC frameworks. That doesn’t accurately describe React, however. Facebook says that React is more of the V in MVC—the View part. The rest of the pattern is flexible with React, but Facebook uses the Flux architecture to fill it out, which is a pattern best suited for larger applications. As a practical matter, plain old React will do just fine for a lot of applications.
It comes in at 120KB when minified and compressed for production, making it the largest framework in terms of file size, although it doesn’t have any required dependencies. Sites using React include: Facebook, Instagram (basically one large React app), Flipboard, BBC and Netflix.
React has a component-based approach that will come quite naturally to those familiar with creating CommonJS modules. Each React component represents a part of the UI - a form element, a page title, etc. These components can then be mixed and matched thus allowing for maximum code reuse.
One very cool benefit of React is that you can use it to create mobile applications. That’s right, React Native allows developers to learn React once, and use it to write both web and iOS apps (Android is coming soon). To me, this is a truly amazing feature.
React also supports server-side rendering. This goes a very long way to solving the performance and SEO problems that have plagued client-side frameworks since their inception. Once the initial page load of the server rendered content has occurred, React on the client-side takes over and updates the UI based on user interaction. Having that first render done on the server eliminates the risk that search engines won’t be able to index the site while also providing faster page loads.
For a lot of developers this just seems…wrong. At least initially. Many come around when they realize that everything concerning a given component is located in a single place. The advantages then become clear - easier debugging, code reuse and separation of concerns. To help get your head around the React approach, Facebook has put together a nice post that walks you through it.
React delivers on the hype. Pretty much any size project can successfully use React and it excels in delivering on all the key things we look for in a framework while addressing the most frequent criticisms. React Native also looks like a game changer.
Perhaps you may be able to guess that I view React as the strongest framework, at least for now. I’m impressed. That said, all of them are good. That’s why they’ve risen to the top of a crowded field.
Ultimately, the framework you choose to invest in will come down to personal preference and the type of projects you or your team want to work on. However, if you’re a developer - particularly a front-end developer - I recommend taking the plunge and gaining expertise with one of them.