fleon (Why I love Ember.js)

Disclaimer: This is my first blog post on frontend web application development, and the content might sound very opinionated and prone to mistakes.

Over time, many people have asked me why I choose to go with Ember.js as framework of choice for my frontend applications. In this blog post, I will outline the various advantages Ember.js has over other frameworks. But before I do so, here’s a bit of background:

Background

The debate started some time last year with my teammates on whether we should use a framework to refactor our heavily interactive application. The answer was pretty clear on that front: Yes. The world of web development has seen far more wheels re-invented than its Desktop counterpart, and going with a framework to build an application and using the knowledge of its community would definitely be faster and reliable than a from-scratch solution. It also helps decouple your application logic from the core design principles like observers.

We started off by researching on candidates for the framework we would go with and decided that our pick would be between Backbone, Ember.js, Angular.js and Knockout.

At first glance, Backbone seemed like a clear winner. It was the most widely used MV* framework out there, with lots of big names using it. It had the smoothest learning curve - it could get you up and running within minutes. On the other hand, Ember.js and Angular.js seemed pretty bloated for our use. We argued that each of them had so many features we’d probably never make use of. Knockout on the other hand lacked the persistence features like sync and save offered by Backbone, which we thought were really handy.

But as we dived in deeper, the opinions of my teammates diverged from those of mine. I was defending Backbone for its simplicity, minimalism and small learning curve. On the counter-defense, one of my teammates argued that though Ember.js might have a steeper learning curve and may look bloated compared to Backbone, but that is because we probably do not fully understand the situations where these features could be useful. I looked for counter-arguments (simply because I hate losing a debate), and  argued that whatever Ember offers could be accomplished with Backbone and Marionette. A couple of more arguments later, I finally agreed that Ember is a clear winner. (Sadly, nobody of us defended Angular.js and it was left alone in the corner. But today, I would consider it as a decent contender.)

Today, when I look back that that long debate, my disappointment of losing the debate suddenly turns into happiness. So without further ado, here are the features why I love Ember.js:

Convention over Configuration

Back during the discussion, I never really understood the value of Convention over Configuration any more than its literal meaning. Now that I understand it, the philosophy is pretty simple. In terms of programming, any repetitive patterns found in code should be handled automatically in by the code using a convention. It helps keep the code very DRY. For instance, if you have a model called Post, there could be a convention that dictates that the corresponding table in the database is called ‘posts’.

If you look deeply, this practice is somewhat in place in programming and other aspects of life far more than you can imagine. At a granular level, the language we speak is a convention we came up with for communication. The syntax and semantics are a convention to a programming language just like grammar and punctuation are to a real language. Learning new conventions isn’t without hiccups, but it can certainly go a long way in solving problems more efficiently.

The developers of Ember realized that there are tons of tasks we do repeatedly during our process of web development, which could easily be made smaller and easier with conventions. That makes up for a lot of glue code you’d normally have to write when using traditional jQuery “configurations”.

To read more about what conventions Ember.js follows and how it can help you reduce your boilerplate code, head over to this post.

Oh, and you would probably argue that following certain conventions makes you forget about the nitty gritty details that go underneath them, or that they could lead to unexpected behaviour if you’re not really familiar with the conventions well enough. Guess what, Ember is totally configurable as well. Head over to the API docs, and thanks to the extensive reference Ember provides, you can quickly find out how to manually do a lot of things.

Handlebars and View Hierarchies

Coming from an ActionScript background, I absolutely fell in love with the concept of view hierarchies, because I could closely relate it to Flash’s display list. You can add child views to your ContainerView or CollectionView and traverse them as fluidly as you can do in Flash. Except that its even better! Thanks to Handlebars templates, the views can now leverage the power of HTML and CSS. (Unlike ExtJS and SproutCore, from which Ember is born, both of which are very distantly decoupled from the DOM.)

Compared to Knockout and Angular.js’s conventions of adding behaviour in the DOM using certain special data-attributes, I find the syntax of Handlebars far more readable and easy. But that is just a personal preference.

Handlebars comes baked in with cool stuff like partials - those little pieces of markup that don’t belong in a particular view, but you don’t really want to repeat the markup over and over again either, and certain other stuff it inherits from Moustache. Ember builds on top of those features and offers even cooler features like layouts and outlets. Layouts, when used in conjunction with partials make it a lot easier for you to extend views. Outlets, on the other hand, can be thought of little boxes in your wireframe where the actual view is rendered.

Read on more about view hierarchies in detail here.

The Lovely Router

The project I’ve working on is a more Desktop-style modal application and haven’t been able to make much use of the Router that Ember.js offers, but from the good things that I have heard, I think that it is nothing less than a piece of art. Underneath the implementation of the Router is a lovely finite-state machine implementation called StateManager. Creating a hierarchy of states your application can exist in is as easy as slicing a cake.

Recently, the folks at Ember introduced a brand new Router that looks even better on the cover. I haven’t dabbled much with it, but if you’d like to know more, Yehuda Katz talked about it during the Ember.js Seattle meetup.

Computed Properties, Bindings and Observers

The trio of these features, in my opinion, is probably the best part of Ember.js. They have become such an integral part of my workflow that today, I cannot even imagine doing most things without them anymore.

It is common to be faced with a situation where a piece of your code performs a task repeatedly over the period of time and gives back an output, and you realize it would be wiser to cache that output to prevent wastage of computation. (Classic time-space tradeoff.) And often you would go writing the implementation of a cache on your own wherever you need it. Throw in a lot of such implementations and things get somewhat cumbersome.

Computed properties to the rescue! This feature is pretty much like getters and setters in your favourite language, except with certain added benefits. One of them is making your property depend on another property, and once computed (get), will remain in a cached state unless the depending property changes. This behaviour being built into Ember makes your application a lot faster without you even realizing it. Alternatively, you could declare your properties as volatile, making it recompute each time it is get.

Head over to Ember’s documentation to learn more about computed properties.

Observers, just like Events.on in Backbone help you observe any property on any Ember object for changes. The observer function will be triggered each time the property is set, regardless of whether it actually changed or not. You could also observe changes on a property before it is actually changed and also send fake notifications of a property change to trigger observers (even if it did not actually change).

Bindings are the layer of icing on top of observers and computed properties. When you make a change in your model, and if something in your view is bound to your model, it will update automatically. Gone are the days when each line your code would include at least one jQuery dollar statement.

You can read more about Observers here and about Bindings here at Ember’s documentation.

The Run Loop

Ember comes with a concept called The Run Loop. It is a really powerful feature that queues up the bindings in the current stack and updates the DOM in the next stack. So if you use Model.set in Backbone twice in a function, and a view is listening for the change, the view would get updated twice, whereas in Ember, the update would happen just once. If you update dozens of properties, the Run Loop would split the DOM updates in as few batches as possible.

The concept comes from SproutCore, which in-turn gets its inspiration from Cocoa. To learn more about the RunLoop, you can head over to the explanation of the concept at SproutCore’s blog here. While it might not be very relevant to Ember, it certainly is a good read.

Ember Data

The last item in this non-exhaustive list of things I like about Ember.js is the much lesser known/used component of Ember - Ember Data. I believe Ember Data is one of the underrated features of Ember and there isn’t much awareness about the doors it opens up for making your applications scale rapidly. Two of the core reasons are: it being in an unstable state and not having any official API documentation available online. But the code is pretty well documented on its own.

From Tom Dale’s talk on Ember Data at the Seattle Ember.js meetup in December, I take away some pretty interesting insights:

• Fixtures help you architect your frontend application without having a backend in place. Just define your model, its relationships with other models, and use DS.FixtureAdapter to populate it with some dummy data. Later down the line, when your backend is in place, you can swap in the fixtures with RESTAdapter, or your own custom Adapter implementation without any other frontend code change!
• The Unit of Work-like pattern implemented with Ember’s StateManager sets your model’s state to ‘clean’ initially, and ‘dirty’ when it is modified by the view it is bound to. Depending on a user action, you could then easily commit or rollback your action, just like an SQL transaction.
• And if you have a REST API up and running using Ruby on Rails, Ember-Rails offers you the functionality to auto-generate models for you. So even lesser work for people using Rails.

Conclusion

From my past months of extensive amount of work on multiple Ember.js projects, my appreciation for what Ember.js team has done has only grown over time. Even though we might have faced issues when upgrading to newer versions of Ember, that is a compromise we had to take for counting on a developing technology. And it seems to rather have had a positive effect on our learning experience. We now know why certain things changed, because we have worked with the older, weaker implementation of things and know where it lacked. I have many more reasons why I like Ember, but they probably belong in another blog post. 

Discuss on Hacker News.