The Ember vs React discussion is still quite lively. Recently I began work on a redesign of a responsive mobile app, and I was once again faced with the decisions about which frameworks, tools and methods I would commit to using. I firmly believe in using the right tools for the right jobs, but there are a whole lot of factors to consider – each of them having a varying amount of importance or relevance to any new project. If you are in the same spot as I am, you might find my discoveries helpful to your own learning journey.
A one-week experiment
A week ago, I decided to spend 7 full days learning a couple of the more popular MV** frameworks, after which I would write a little about my learnings and make a choice for my newest project. I had watched a presentation called Comparing Hot JavaScript Frameworks: AngularJS, Ember.js and React.js by Matt Raible, and was inspired to quantify my framework selection a little more thoroughly, even if inevitably I make my choice from the gut.
So I performed my experiment on two of the top three JavaScript frameworks – Ember.js and React.js. I’ve played in the sandbox with AngularJS in the past, and have attended a number of developer meetups and sessions as well, so I already had an idea of what developing with AngularJS was like. Here are the factors I considered:
- Learning Experience (LX)
- Developer Experience (DX)
- Testability
- Security
- Build process/tools
- Deployment
- Debugging
- Scalability
- Maintainance
- Community (aka Sharability)
This is the same list Matt used in his presentation, and it works great. The important thing to recognize is that these factors will weigh differently for you than for me. Consider assigning each of the 10 factors a decimal weight between 0 and 1 based on fit for any project before you actually fill out your own matrix, and then apply that weighting to your final scores. Doing this with basic formulas in an Excel doc or Google Spreadsheet is trivial, so use one of those to make it easy on yourself.
I spent 3 days creating the first screens of my new app in React, and then 3 days creating the same screens in Ember (and for those doing the math, 1 day composing this post.) For 10+ hours each day I enveloped myself in tutorials, videos, docs and podcasts in an effort to learn as much as I could about each framework. It’s important to actually write code during your evaluation process! Don’t assume that because a framework works well for others that it will be the best fit for you or your projects.
TLDR; Ember won. The areas where Ember really racked up points in my selection matrix were in Developer Experience and Community, and instead of talking about why React and Angular didn’t win, I’d like to talk more about why I chose Ember as the best fit for my application redesign.
Developer Experience
DX is a play on the UX term, and as you can imagine, it refers to how a particular tool or library is designed to make developers’ lives easier. The Learning Experience factor is heavily entwined with the DX factor, especially as your knowledge grows and you move into more advanced code and real-life challenges.
Here’s how Ember.js ♥’s developers.
ember-cli
The ember-cli tool didn’t seem to be a huge benefit for me when I first looked at Ember.js, but being able to ember serve a new project immediately was encouraging. As I began generating new routes, templates and models I realized how much time the CLI tool was saving me.
# A single command to create a route, model and template for a new class
ember g resource users firstName:string lastName:string email:stringThe command above will generate code for your User class’ route, template, and model (with properties) saving you from writing, copy/pasting and search/replacing code manually.
What’s interesting is that ember-cli has become the expected way of generating code, testing apps, and even serving the development environment. And much or most of the documentation for Ember.js 2.5 has been updated to use the CLI tool, so the Ember.js team is betting big on it. I expect that I’ll put the tool to through its paces more as I begin setting up tests and adding more to my build process.
LTS release channel
When I first began building and maintaining production Linux environments – especially clustered environments with multiple layers of load-balancing, reverse proxies, caching and lots of dependencies – I learned the importance of Long Term Support (LTS) releases in Ubuntu. When the Heartbleed and POODLE vulnerabilities in SSL surfaced, for example, patching OpenSSL was critical. But if you were running on a non-LTS 13.10 version of Ubuntu like I was, suddenly patching a security vulnerability meant upgrading your entire operating system. Yikes!
Ember has adopted the mantra of “stability without stagnation”, and this resonates loudly with me. Ember 2.4 was the first LTS release, and every fourth release will also be LTS.
LTS releases will receive critical bugfixes for 6 release cycles (36 weeks). This means we will support Ember 2.4 LTS with critical bugfixes until Ember 2.10.0 is released, around November 4, 2016.
LTS releases will receive security patches for 10 release cycles (60 weeks). This means we will support Ember 2.4 LTS with security patches at least until Ember 2.14.0 is released, around April 21, 2017.
An LTS release channel means addon developers know where to concentrate their efforts, and Ember.js users can upgrade less frequently and more confidently, while still having access to the latest features, bug fixes and security patches.
The Learning Team
Because learning is more than just docs. The Ember.js Learning Team is responsible for all the different ways that users learn and grow with Ember, and for ensuring that the learning experience remains a central component of future releases. At EmberConf 2016, Yehuda Katz & Tom Dale announced the role of the Core Team and the subteams.
Watch a video of Recardo Mendes talking about the new Ember.js Learning Team at EmberConf 2016.
Browser dev tools
The Ember Dev Tools make understanding how your application is working a snap, and they are available as extensions for both Chrome and Firefox. You can also use a bookmarklet for other browsers.
Want those same dev tools on your mobile device? Check out the ember-cli-remote-inspector which makes it easy to debug your application on your mobile device using your Ember browser extension through websockets.
ES6
I like TypeScript but it doesn’t feel like I’m writing JavaScript, and I never really got into CoffeeScript, but I really enjoy the idea of writing standard ES6 code. Since that is the direction that browsers and the community are heading anyways, why not start writing that code now? Tools like Babel.js make authoring in ES6 or ES7 easier by transpiling to JavaScript that current browsers can understand, and without requiring full browser support for the latest versions of the language.
The Ember.js Community
Here’s where I’ve fallen in love with Ember.js – the community. As an active WordPress developer, WordCamp speaker and blogger, I’ve become accustomed to the WordPress community, and maybe even spoiled by it. The community constantly amazes me with the number of willing contributors to core, to plugins, and to documentation and learning.
Learning
There are some great community resources for learning Ember.js:
Search Meetup.com and you’ll find Ember groups near you who meet often to learn from each other and freely share their knowledge and love of Ember.js.
Forums
Check out http://discuss.emberjs.com/ for active forums using the robust Discourse forum platform (my favorite forum software, and also built on Ember.js!)
Watch the video
Take a look at the video, it’s long but it does a great job demonstrating the thought process process behind selecting the right JavaScript framework for any project or organization. The weighting of the factors for Matt or myself may be very different from yours, so be sure to go through the exercise yourself and see which framework is best for your requirements.