28 October 2014
The Evolution of Ember: A Look at Its Past, Present and Future
Let me take you back to January 2013 and the darkest days of Ember. For my co-workers and I, it was the heyday of “Ember vs. Angular.” We knew that each had a lot to offer over our current Rails and Backbone stacks, but OMG, WHICH ONE TO CHOOSE?
Ember 1.0
Ember spent over a year in 1.0 “prerelease” status, and the ethos of developers that tried it seemed to be “it’s too big and too bleeding edge.” Angular, on the other hand, was stable enough to use on real projects and allowed us to add just the sprinkles that we had grown accustomed to using in Rails and Backbone.
Ember Data
Even after Ember 1.0 finally arrived another concern remained: What would become of Ember Data? People asked if it was fundamentally broken while several alternatives to Ember Data began to arrive on the scene. Development activity slowed to a crawl during the summer of 2013.
Documentation
Developing with Ember before 1.0 involved a lot of code reading. Not necessarily all bad, but the core team routinely got the feedback, “your documentation sucks.” Ember already had a reputation for having a big learning curve and poor documentation compounded the problem.
Turning Around
As much as I enjoyed Ember’s ambition, I’ll admit that I was bearish on the future of the framework. Angular was the next obvious step beyond Backbone and I worried that Ember had bit off more than it could chew.
But somehow it slowly, painfully turned around. Even with a strong community of contributors, it’s hard not to imagine Yehuda Katz extracting Tomster from that swamp in the Dagobah system using the force. Or maybe that’s just me.
As our Gaslight CEO so aptly told Yehuda:
You go into really hard things, power through it, and everything gets better.
Ember 1.0 finally arrived and Ember Data started getting the love it deserved. Trek Glowacki led the charge to bring the documentation up to snuff.
The project adopted a six week release process inspired by Google Chrome and introduced feature flags to allow new experimental features in the code base. At the same time, the core team showed commitment to backwards compatibility. Ember became stable and predictable. Confidence and excitement was building.
Ember’s Strengths
Today Ember may not be as popular as Angular or Backbone, but I am bullish about its future. We’ve seen a growing number of companies using Ember, but to me, it’s all about the benefits for developers.
The Router
It’s hard to explain how much this part of Ember just works and addresses many pain points in front end development. Maybe the best thing we can say is that it is a high priority feature for Angular 2.0 and that when well-known Ember developers began getting more involved with React, it was quickly ported.
Computed Properties
Composing state with computed properties in Ember is truly a joy. When it comes to managing state over time, I agree with Alex Matchneer that Ember has “clearly tamed that beast”. The expressiveness achieved with Ember’s computed property macros is beautiful and it’s only getting better.
Ember Data
While there are still some lingering issues that need to be worked around
(notably a couple issues with
isDirty), Ember Data has reached a tipping point where its value is massive
and the cost of its quirks are minimal. It’s heavily customizable and introduced
me to concepts like side loading that I now can’t live without.
At this point, no other library tackles the problem of a front-end data with as much success as Ember Data does. However, one might point to Meteor as an example of a full-stack platform that greatly simplifies client-server data concerns, albeit at the cost of dictating your server-side stack.
What’s Next?
Testing
While Integration Testing1 with Ember is quite pleasant, testing the individual parts of an Ember application is awkward. I attribute this struggle to the transition from using global namespaces to using ES6 modules and the need to use Ember’s run loop in unit tests.
While there are attempts to improve the situation, I believe there is significant room for improvement.
Components
There is undoubtedly confusion about the role of ember
components. Their functionality seems to encroach on other
parts of the framework like views, item controllers and render. At the same
time, they provide a way to eliminate some of the less understood concepts in the
framework with a more general-purpose abstraction.
I enjoy the approach explained in talks from Trek and Ryan Florance advocating small, reusable components on the scale of what HTML already provides. However, the influence of “everything is a component” ideas from libraries like Polymer and React encourage people to use components to design larger, domain-specific portions of their application.
In my opinion, we’re dealing with a problem in vocabulary, and as Tom Dale indicates, vocabulary is important for Ember.
[Developers need] both sophisticated tools and the right vocabulary of concepts to help them communicate and collaborate.
With time I hope we’ll find the sweet spot for components or at least some way to describe the different types of components that we build in our applications.
Services
The introduction of services came and went without too much fanfare, but I anticipate this concept will have a significant impact on Ember. In short, services are a declarative way to open a line of communication between parts of your Ember application.
Services are little more than a name, and don’t provide any functionality that wasn’t already possible in Ember. However, they provide a way of unifying what were often ad hoc ajax requests and strained uses of controllers. I’m excited to see how the community uses services when they step out from behind their feature flag.
Training
I’ve been excited to collaborate with Tilde on an update to their Introduction to Ember online training available from their website or ours. Updating the course has given me a chance to see how Ember has evolved over the past year and a half. If you’re interested in seeing my work, please consider purchasing early access to the training at a reduced rate.
Footnotes
- The Ember guides use this term to describe tests that must operate on a running application.
