Why I Chose Ember.js

Clarification This article has been edited to reflect time spent with each framework and a few other relevant facts

I have finally made the plunge to really dig into Ember.js. But, if you are familiar with the vast landscape of Javascript frameworks, you may wonder why I chose Ember.js. This isn't a light decision and Ember.js is thought to have quite a steep learning curve. However, I think that there are some reasons behind this that I will cover in a later post.

So to start, let's look at the various frameworks and my own relations to them in my track to eventually set upon Ember.js.

Backbone.js - 8 Months Experience

When looking at front-end frameworks, many first happen upon Backbone. However, I find that Backbone is more of a library than a framework. Think of it as a bit more structure than jQuery. But, it is far from an experience of being what MVC, Rails, Django, or Laravel are in the server.

Backbone is an incredible bit of kit for managing some light data binding but soon becomes hard to manage. The patterns that arise become, if you would pardon the pun, back-breaking. But, this being said, Backbone clearly has a use case in form validation where jQuery alone can become a bit awkward.

Marionette.js - ~4 Months Experience

Of you work on Backbone projects you quickly become tired of the boilerplate that is associated with Backbone apps. To answer this, Marionette was created to manage some of the common issues with Backbone. It is a valiant effort and live bindings definitely becomes more of a possibility with Marionette. But, after working with Marionette, there were things that were a bit awkward and there was always a good deal of boilerplate.

Working with Marionette was a nice improvement, but I felt that it was a bit bulky for the gains. Making full interactive sites was still strange. Marionette does a great deal to try and make Javascript web apps closer to server or desktop development, but it doesn't quite make it all the way.

Ember.js - Take One 1 Month

My first experience with Ember.js was about six months ago, and it was a love hate relationship. Looking at the documentation and a few talks about Ember, I was really intrigued. It looked like it was as simple as many of the server-side frameworks in the way that it worked.

After trying to get started, it was pretty clear that Ember was more to take on than I had thought. There were version conflicts and huge API swings that made creating simple starter apps difficult. Since there were these large API changes, Ember tutorials were few and what was out there always seemed to conflict with newer conventions.

However, in trying to learn Ember for the first time, I had a few take aways. First, I really wanted it to work! From the demonstrations given by Tom and Yehuda I knew that Ember was going to be awesome, but it had a learning curve. Second, front-end frameworks needed tooling. While it is all well and good to write templates in the HTML rendering pages, this didn't scale. And working for a CTO that made me write JST's by hand made me sour to that idea as well. Third, I needed more examples outside of using rails. Ember still to this day has far too many tutorials saying "use serializer here" and "gem install ember-rails".

Angular.js - 1-2 Weeks + Hackathon

It's hard to mention a framework battle without mentioning Angular. It is the Google-backed uber framework for front-end development. However, after going through an introductory course, I found that while it was cool for making a live-markdown parser or a todo list, going beyond that felt like a whole foreign environment.

On top of this, Angular killed the idea of the DOM. Various ng-attribute references cluttered the page around and this was mixed with what is called "mustache-esque" template bindings. It was all quite confusing.

Beyond this, Angular seemed to use some type of Klingon for tasks that seemed quite common, and while I spent a good deal of time in University studying Computer Science, I rather don't like trying to figure out directives, scope, or transclusions.

Even past then, Angular did not do well with nested resources which are quite common in my applications. I just didn't figure out how you could have a shopping cart with many orders each with many items and yet keep all that from becoming an absolute mess. And to make things worse, I haven't had first hand experience with this, but I hear that uglifying or minifying angular is a bit like the Aisle of Terror. Maybe I didn't give Angular the time it required, but I'd rather go do something fun than sit around writing dissertations within my code.

Knockout.js - A few tutorials

My experience with Knockout.js is quite limited, this is just my quick opinions that made me shy away from it.

After looking around for more live-binding frameworks I found Knockout.js. Honestly, in my quick glance at Knockout, it seemed a bit like Angular lite. There were some things that I liked but I still found myself yelling at a framework that reinvented the wheel of templating and even said "you can substitute our version of handlebars with handlebars". If you base your software off of another software then just go full tilt and use that (especially something as flexible as handlebars). This once again cluttered the DOM and had me scratching my head with what to do to move the files out of my markup and into separate template files.

All of this was only compounded by the fact that Knockout is really tightly coupled to .NET implementations. It's so bad that Knockout users joke "oh I see you loaded Knockout, what version of MVC are your running". Just stop! If your front-end framework won't work with any server-side framework, go back to using turbolinks.

It should be noted that Knockout is able to work outside of .NET, from what I looked at, the community was extremely heavily weighted to .NET users as was the tooling available. This was a major con for me due to my limited access to .NET in order to compare what was going on in terms of server interaction.

Batman.js

Ok, honestly, I haven't tried, looked at, or even coughed in the general direction of this framework. But… It's called BATMAN so how could I not mention it! From the front page it looks a bit angular-ish with HTML5 compliant data attributes instead of of ng-garbage.

Ember.js - Take Two

Fast forward to a few weeks back and I was caught up in watching the Ember vs Angular cage match. Watching the video, I saw that Ember had solidified and was easier to start up than before. Listening to the Ember Hot Seat, by suspicions were confirmed: Ember was getting close to what we had dreamed about. To make things even better the tooling was light-years ahead of where it had been and started to become a bit more detached from the Rails Asset Pipeline. Things like Emberscript, Ember-Tools, and grunt tasks have made Ember much more framework agnostic.

So, I took it upon myself to really look at the documentation and work through the getting started guide. After finding a few kinks in the system, I soldiered on and then ported the Fixture (think DB seed data) to local storage and then to a RESTful client using Laravel as a backend. From there, I decided to really look at relational data as it was the final thing keeping me from really moving to a front-end framework. Sure enough, I looked at Ember Data's relationships and they worked really solidly. So, now I have made the switch and have joined the Ember fan club.

Conclusion

In my experience, if you are creating heavy RESTful front-end apps, Ember is your framework. It cuts out almost all boiler plate and makes many convention based decisions for you. This cuts out on time when developing an app once you learn what Ember wants to do by default. What makes it even more powerful is the fact that the Ember Object Model makes the entire framework easy to modify.

However, when you are running smaller apps or widgets, I would suggest running regular Backbone. It gives you just enough abstraction around jQuery to make data binding and view based event handlers really easy. But if you find yourself reaching for Marionette or Chaplin, I'd seriously consider making the switch to Ember It's just better to work with something that was built for the kind of work you were doing from the start instead of using an extension of Backbone.

I still would like to see more non-rails developers adopt Ember and share their experience. I think this will benefit the community as a whole and will start to demystify some of the complaints on HackerNews and the like.

In terms of spending time in other frameworks or "looking at X" again, while I wish I had the time to do so, every developer eventually needs to stop and just get work done. Ember filled the needs for many of my larger applications. I continue to keep my eyes out every few weeks to see how the landscape changes, but I am rather set for now.