If you have recently blinked, it’s likely that you have missed the plethora of web development tools, frameworks, etc. There is one in particular that has my full attention however, Ember.
Full disclosure, I have spent far more time exploring Ember than similar tools like Angular, Backbone, Knockout, React, etc. Given that, this will not be a comparison of frameworks and tools, instead, just why I think Ember is completely awesome.
Reasons To Love Ember
Convention is a huge deal with Ember, and it’s something you’ll either love or hate. Let’s say your application has one resource
Post. Once you declare a
Post resource, Ember will look for the following:
- post.hbs (Handlebars template)
The names here are important. If you spell
PostController incorrectly, it just won’t get picked up by Ember. Tools like Angular aren’t as convention driven. Developer A could create
PostCtrllr while developer B creates a
PostController, both of which are perfectly acceptable. I’d wager that someone familiar with Ember jumping into a legacy Ember application will come up to speed much faster then a developer familiar with Angular jumping into a legacy Angular application. Again, it’s not that Angular is bad, it’s that there’s a lack of convention.
Model View Controller - a familiar software design pattern. If you have spent any time doing web development with other frameworks, like Express, Rails, Zend/Laravel/Cake, etc. it’s very likely that you have come across this pattern before. The MVC principal in Ember is basically the same.
If you’re getting started with Ember, you’re probably looking at Ember CLI. Ember CLI uses the ES6 Module Transpiler so you get ES6 support built in. Ember CLI’s build tool Broccoli gives you lightning fast application builds; no more do you have to wait for Grunt to finish. Ember also comes with Promises built in.
Data-Binding & Managing State
For a common task of fetching data from a server and displaying the data, the flow might be:
- Click X
- X’s state changes to “loading”
- Make AJAX request
- On success, update DOM, revert X’s state. On failure, notify user, revert X’s state.
Using a tool like Ember can essentially remove all of the DOM/state manipulation that you would otherwise do by hand. Because the DOM is bound to a model, as the model updates, so does the DOM, automatically. So you’re doing the same function, but writing a lot less code, that’s more maintainable.
Ember Data is an optional library to manage your application’s data. I say optional because like a Birthday party, you can technically not serve cake, but if you don’t, everyone will cry a little on the inside.
Ember Data can be thought of as an ORM, with a consistent data retrieval/persist interface as well as adapter architecture that can be used to connect Ember Data up to any datastore without effecting your application logic. Also there’s promises! Here’s an example:
Easy right? As mentioned before, what’s great is that not only is this easy to use and understand, you can swap in a different adapter if you want and your code here stays the same; it just persists to a new place.
Ember Inspector is an awesome tool that works in most modern browsers. It provides developers with lots of things like view hierarchies, resolved/rejected promises, a look into the data store, routes/controllers/views that it knows about, etc. Developing an Ember application without it could be dismissed as crazy talk.
I mentioned Ember-CLI and Broccoli earlier. Ember-CLI has a growing list of addons that helps you be more productive out of the gate, while Broccoli supports all of the things you’d expect like SASS, LESS, CoffeeScript, etc. Of course you can still use Grunt or any other build tool of your choosing.
Testing Support Built In
Ember-CLI comes with built in QUnit and Integration test support build in. Every time you generate something through CLI:
ember generate controller foo
Not only does this scaffold your controller, but you get a corresponding unit test. You elaborate on these generated tests of course, but Ember CLI is doing the grunt work for you, making sure you don’t ignore testing. There’s also built in support for integration testing which is achieved through Ember Test Helpers. If you’ve ever written acceptance tests for Selenium, these are kind of the same thing, only much more performant with less overhead. Did I mentioned speed yet? Both QUnit and integration tests are so fast, that it’s not unheard of to re-run your entire test suite in between saves. That’s pretty powerful as a developer, knowing if I broke something within seconds rather than minutes.
While I don’t think the Ember community is quite as large as Angular’s, they are just as active and engaging. If you live in a major market, chances are there’s an EmberJS Meetup near you.
Reasons Not To Love Ember
Depending on where you’re coming from as a web developer, your intro to Ember may fall somewhere between “painful” and “please shoot me in the face”. When I first dove in to Ember, I was coming from the traditional jQuery build-everything-yourself world of web development. It definitely took me some time to get into, but once I did, my productivity increased. Think Logarithm curve; that initial curve is steep but it starts to level off.
I’d recommend people new to Ember to approach it with a small project in mind. I find it a lot easier to learn something when applied to a topic of your choosing than to step through more trivial tutorials.
Ember documentation is getting better. However, Ember is very actively developed and it’s quite possible that the documentation you’re looking at from 6 months ago is stale.
Having spent a year with Ember, watching it evolve, going from “global Ember” toward Ember-CLI has been a blast. For me, Ember makes web development fun. Never once do I really feel hindered by the framework and given that most of the mundane stuff is abstracted for me, I can really focus on things that matter like UI/UX, features and being ambitious with my applications.