The Case for Ember

on emberjs, javascript, front-end, web-development, enterprise, ember

For Enterprise

As time progresses, enterprises are starting to more aggressively adopt front-end frameworks. The big push for thick-client web applications has hit the enterprise, and hit it hard. Technical leaders at enterprise companies see the benefits of single page web applications (which we won't delve into here), and want to create them on an enterprise scale.

This holds true for my current place of employment. My company has been through many changes over the years, from the days of PowerBuilder, to simple ASP.NET WebForms, to Silverlight, and now to thick-client web applications. We want to use modern technologies to create a great user-experience that keeps our customers satisfied with the service we provide.

In the end, we landed on using Ember to accomplish our goals. My purpose in writing this post is to let you know how we landed on using Ember, and why I believe Ember is the best choice for enterprise companies in the current landscape of front-end frameworks.

Goals

Our company currently uses a product called "KendoUI" from Telerik to create our single page web applications. Kendo has many different components (binding framework, router, etc), but they are disparate pieces and not tied together in any way. Due to the way Kendo is currently structured, it required the organization to write a home-grown framework that glues the pieces together, which causes a lot of pain and suffering in an enterprise environment (we'll discuss that more in the "Ease of Use" section below). After dealing with the pain for some time, we convinced the appropriate parties that it would be best to switch to a more mature and fully baked framework.

When evaluating new frameworks, we took the following things into consideration:

  • Ease Of Use
    • How easy is it to maintain consistency across the enterprise?
    • How easy is it to get new developers up to speed?
  • Problems Solved
    • What common problems does the framework solve for us?
    • What benefits do we get from using the framework?
  • Future "Proof"
    • How does the framework take into account the future of the web.
    • How likely is it to either radically change or be abandoned?

At this point, our main contenders for front-end frameworks were Angular and Ember. You may be saying to yourself "why didn't they consider X"? The fact is that there are many other frameworks which we could have considered such as Backbone, Knockout, Sammy, and the list goes on. The bottom line is that these two frameworks, Angular and Ember, are the two heavy hitters in the category of fully-featured front-end frameworks.

Angular and Ember both provide the complete set of features needed to create a full-feature, thick-client application (such as routing, data binding, etc). The other options don't really provide all of that functionality, so we narrowed our focus to these two frameworks. Let's get started.

Ease Of Use

When working in an enterprise environment, you always have to not only consider how a particular piece of technology will work for you and your team, but how it will affect the entire organization. This holds especially true when making a big decision like choosing a front-end framework that will eventually be used across the entire company. In this area, Ember won out for a few different reasons.

Convention over Configuration

If you're not aware of what Convention over Configuration is, I'll give you a short (Wikipedia) definition:

Convention over configuration...is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.

I don't know about you, but after working on technologies that have run the full gamut (from complete configuration to complete convention), I will choose convention pretty much every time.

In an enterprise environment that consists of many developers stretched out across many teams, the usefulness of this design paradigm cannot be overstated. If convention over configuration is not employed in an enterprise environment, you will most likely end up in countless meetings, discussing / arguing over the most menial design decisions. By employing convention over configuration, many of those design decisions are made by the chosen convention, and are no longer up for debate.

Ember is designed with a convention over configuration philosophy in mind. By designing the framework in this way, the amount of developer ambiguity on how to develop an application with the framework is greatly reduced. However, if you encounter a situation where the convention does not work, Ember provides mechanisms to override the convention and allow you to handle it in your own way.

You may also hear it said that Ember is a very opinionated framework, which is absolutely true and is a direct result of this philosophy. Ember employs strong, industry-tested opinions at its core. This helps development teams really focus on features and adding business value instead of getting caught up in meetings and discussing how to do things throughout the entire development process. The Ember team contributed heavily to Ruby on Rails, which was actually an inspiration to the ASP.NET MVC framework. Since our company consists of mostly .NET developers, this will allow them to see similar patterns and make the adjustment a little more easily.

Angular was not designed with a convention over configuration philosophy. With this framework, the vast majority of design decisions are left up to the developer. Many design decisions are debated, even among the Angular community. For example, if you go to a forum and ask a question like "where do I store my model in Angular?", you will receive a few different answers. There is no convention which dictates how things should be laid out or how certain tasks should be coded. This increases developer ambiguity and results in meetings to make simple design decisions, leading to decreased productivity.

Additionally, when dealing with an enterprise, the results of all of these meetings will need to be documented so that future developers can be brought up to speed. This leaves you with pointing developers to two different sources of documentation: official Angular documentation, and your company's documentation. You wind up with the burden of teaching new developers "The AngularJS Way" of writing applications.

Some people enjoy the freedom that Angular gives by it's lack of conventions, and I'm not knocking that at all. However, for an enterprise environment, this spells trouble 9 times out of 10. In fact, the Angular team really likes the convention over configuration paradigm, so read this post to see how they’ll be inserting convention over configuration into version 2.0 of their framework.

Documentation

When looking at adopting a new tool or technology in an enterprise organization, documentation is key. The ability to get developers up to speed quickly is hinged on documentation, whether that be internal or community-driven. With the former, the organization must commit the time and effort to generate good documentation, or productivity will suffer. With the latter, the organization can simply point developers to the documentation site without investing signficant resources in generating documentation.

Although Ember once lacked in this area, it has since made huge strides and is one of the most well documented frameworks available. Their main website is filled to the brim with tutorials, code samples, and advice on using every piece of the MVC framework. Ember's public API is also very well documented, something that many times goes understated or is ignored altogether.

For Angular, documentation has long been a source of pain for the development community. A majority of their public API documentation lacks relevant code samples. For example, if you take a look at their documentation for routes, you may find it lacking. This is especially concerning, since routing tends to be the backbone of a single page application.

Problems Solved

When looking at adopting a framework, you should always ask yourself these kids of questions:

What does using this framework buy me? Reduced code complexity? Great solutions to common non-trivial problems?

Why should I use this framework instead of writing everything from scratch?

The major players in the front-end framework arena definitely allow you to answer these questions in a way that results in favoring use of the framework. The question then becomes this:

Which framework buys me the most, and solves the most common problems in the best way?

State Pattern

When dealing with large front-end applications that are UI heavy, utilizing the state pattern will make life a whole lot simpler. The use of the state design pattern is very popular in computing and has entire books written on it, so I won't go into detail here. Just know that using said design pattern is very useful in UI heavy applications.

In Ember, the state pattern is a 'golden rule' and is baked right into the framework's core. Angular, however, does not express this opinion. Since we're dealing with UI heavy applications, we would need to build our own state pattern in Angular. This comes along with the added baggage of creating documentation around our custom code as well as enforcing that everyone else abides by those rules.

The fact that Ember bakes the state pattern into its core saves us from writing our own and re-inventing the wheel.

Templating

Most front-end frameworks make a distinct choice on templating language. Sometimes this can be overlooked, but I think it's an important point to consider. Picking a good templating language will allow you to create a solid separation of concerns and save you headaches in the future.

Ember uses Handlebars templates, which by nature are logic-less. Logic-less templates provide a solid pattern on which to build unit tests. They also force you to decouple your front-end logic from your markup, creating a clean separation of concerns.

In contrast, you can embed logic in your markup with Angular. It is very reminiscent of classic ASP with if statements scattered everywhere. In order to maintain a clean separation of concerns, you would need to set down strict documentation on how to write templates and come up with some sort of mechanism to enforce this strategy. Just like the lack of convention over configuration in an enterprise environment, this can spell trouble very easily.

Data Store

Creating a mechanism to persist data in some manner is central to a web application. If you're working on a web application in an enterprise environment, you will have to deal with persisting data at some point.

Although it is currently in beta, Ember Data provides a very nice abstraction layer that supports interaction with a variety of data sources such as RESTful APIs and local browser storage (for off-line use). It also allows for custom providers to be created.

Angular, on the other hand, has no method for dealing with the persistence of data. All data access has to be hand-coded. If you're interacting with a RESTful API, this means making extensive use of either jQuery AJAX or low-level coding with XHR. It also does not present any opinions on off-line behavior.

The fact that Ember has a mechanism in place to deal with persisting data solves a very common, and often non-trivial problem that most web applications have. The fact that this mechanism works very well and is constantly being improved makes it an even bigger win.

Future "Proof"

To address any concerns on my usage of the words 'future proof', I want to point out that I am not saying Ember is 'future proof' today. I would not say that any framework that currently exists or ever will exist is 'future proof'. Let me define what I mean by 'future "proof"':

Future "Proof": the ability of a framework to take into account the ever-changing nature of the web, and its ability to adapt to change.

In looking at the history of Ember development, as well as Ember's current state of affairs, it is abundantly clear that the core development team is dedicated to keeping the framework up-to-date and using the latest technologies. Not only is the Ember team dedicated to this, but they've also made it clear in "The Road to Ember 2.0 RFC" that they plan to do so without alienating developers using the 1.x version of the framework.

The fact that the Ember team utilizes the RFC mechanism for sharing the roadmap of Ember with the community speaks volumes about their committment to the community. For those unfamiliar with the concept, an RFC is a request for comment(s). From the Ember RFC Github page:

The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the framework.

If you read through the above link, you'll notice that they have a process for submitting an RFC. Within that process, there is a step to create the RFC and submit a pull request to their Github repository. This step is extremely important, since its whole purpose is to gather feedback from not only the core team, but the community as a whole. This allows many ideas and real-world scenarios to be taken into consideration before any further action is taken. That is a huge plus for the community!

Throughout the course of the year (2014), the Ember team made quite a few strides in keeping the framework on the cutting edge. They invested in open standards such as JavaScript modules (ES6), promises, and web components. They also invested heavily in ember-cli, so that developers wouldn't have to continue rolling their own build pipelines for their Ember applications.

The Ember team has no plans of slowing down in the future, either. They take on an aggressive 6-week release cycle and constantly add new features. As stated in the RFC, the team plans on making ember-cli and ES6 modules first-class citizens moving forward, and they are also adopting concepts from other frameworks (such as the virtual DOM from React). This shows that the team is absolutely dedicated to keeping the framework 'future "proof"', according to the definition I've given above.

Now, I in no way mean to detract from all the strides the Angular team has made over the past year. They've done a lot of really cool stuff, and Ember actually learned from a number of Angular items. Healthy competition in this arena is great for the community, and needs to continue. Without that competition, we risk stagnating, and we surely don't want that!

Also, with the recent announcement of Angular 2.0, the core developers have publicly stated that there is not a migration path from 1.x to 2.0. Though I can see the benefit in this, I really feel that the core team may get enough of a community backlash and reconsider their decision. In fact, Rob Eisenberg's blog post "All About Angular 2.0" is a clear indication that the team is currently taking some heat from the community. Rob is a core Angular developer, and he's pleading for the others on the team to reconsider their decision, as well as encouraging the community to speak up about issues they may have with the whole situation. All in all, I think this will be a great product and I'm looking forward to Angular's new release, which is slated for sometime near the end of 2015. In fact, good competition within UI frameworks will only benefit us as consumers!

Since the Angular 2.0 announcement hadn't yet been made when we made our decision, it was not a deciding factor. However, it sure makes us feel even more confident in our decision to go with Ember. It would also be a major deciding factor if we were having the discussion right now as opposed to a few weeks ago.

Engaging the Enterprise

As a [very] brief aside, I want to point out one particular RFC that demonstrates the Ember team's ability to recognize their user base. This RFC was created by Tom Dale and focuses on the fact that many enterprises have been adopting Ember. From the RFC:

Large companies are increasingly adopting Ember.js to power their entire product lines. Often, this means separate teams (sometimes distributed around the world) working on the same app. Typically, responsibility is shared by dividing the application into one or more "sections".

Sometimes, each "section" will be a completely separate Ember app, with a shared navigation bar allowing users to switch between each app.

It just so happens that my company is going to run into this exact scenario in a year or so. We have many 'sections' that would best be structured as their own individual Ember applications. The fact that the core team has taken this scenario into account speaks volumes about their committment to their framework and their developers.

Conclusion

In the end, the immediate usefulness of Ember, combined with aggressive updates and the committment of the core team, made the decision pretty straightforward.

Ember wins out when it comes to ease of use:

  • Convention over Configuration
  • Very well documented

Ember solves many common problems, and solves them well:

  • State pattern
  • Templating
  • Data store

The Ember team has also shown that they are dedicated to "Stability without Stagnation":

  • JavaScript Modules (ES6)
  • Promises
  • Web components
  • Gradually introducing advancements while maintaining a clear migration path for current users
  • Keen awareness of enterprise adoption of the framework

All in all, the current version on Angular has just enough technical debt built up that Ember is the clear winner for our organization today. Don't just take my word for it though, read through the following link: http://eisenbergeffect.bluespire.com/angular-and-durandal-converge/. Rob Eisenberg is the creator of Durandal, and is now a core member of the Angular team. That link describes in detail how he will be assisting in the Angular 2.0 re-write and incorporating some core ideas from Durandal during the process. I highly recommend reading through that article to get a better feel for the reasoning behind the decision to re-write Angular from the ground up, as well as get some more insight on the things to come in Angular's future.

A big thanks goes out to the following people for helping me edit / refine this post:

As always, if you have any questions / comments, don't hesitate to drop me a line on twitter (@awgreenarrow), shoot me an e-mail at andrew@greenarrow.me, or write your own blog post and let me know about it via one of the first two methods!