Before I get into the nuts and bolts of our process, it’s important to chat about why Ember is better for design iteration (at least in an agency setting) than most other javascript frameworks & libraries.

This is not about data immutability or render speeds. This is about running a better business through a deeper understanding of technology.

Things like React, Flux, Backbone and jQuery (amongst many others) fall into the category of “progressive enhancement”. They’re libraries that bolt on to a server rendered template, and allow it to do things it couldn’t do before. On the surface, this seems great — you add bit and bobs to the good old browser environment, and only use what you need.

However, as an ambitious project matures, so does the UI, and it’s requirements. So you reach out and grab another library that does another thing, and then write some ~simple~ code to make library X work nicely with library Y.

Progressive Enhancement sucks when there’s churn in the project’s maintainers.

Leaving a team with a Fat Slab of Custom Code™ that bolts libraries together, and then bolts those libraries to the browser and API means a brittle, unmaintainable codebase.

Custom code in an agency setting is a huge liability (unless you’ve got some amazing employee retention, or infinite time, that is…)

Enter technologies like Ember, Meteor, Angular and others. Instead of enhancing the browser with a slice of functionality, they act more as a full application stack that runs in the browser environment, and provide developers with a shared solution for common tasks (routing, presentation logic, data fetching + modeling, and so on).

“At some point recently, the browser transformed from being an awesome interactive document viewer into being the world’s most advanced, widely-distributed application runtime.” — Tom Dale

In exchange for this enormous productivity boost, you’ll lose some low level control over the browser’s fabric. Experienced developers are usually uncomfortable with this, but that’s happened before…

*cough, Rails*

Something that isn’t immediately obvious, however, is how quickly an opinionated framework can help you identify patterns and core themes throughout your work.

Rails helped us do this with service layer programming — and now Ember is helping us uncover hidden workflow efficiencies for the user interface.

Whether you agree with it’s opinions or not, an opinionated framework surfaces non-obvious efficiencies for both the codebase and business.

Sam Selikoff’s (@samselikoff) Ember Conf 2015 is illuminating: