I was able to catch a session with Jonathan Jackson of Hashrocket, co-author of EmberCLI Rails gem and founder of the Ember Weekend podcast, at RailsConf 2015.
98% of building good apps is understanding your layers and knowing where the code should go.
Ember breakdown
EmberJS is a MVCR javascript front-end framework for developing dynamic web applications.
Routers are the way embers serializes data. There’s the application stat and it updates the URL per route, so we can use the browser’s back button and history.
Views and controllers are going to be merged in Ember 2.0.
Rails and Ember have a lot in common
There are a lot of cross-over ideas from the early version of Rails to Ember, which means that today both systems have common values.
For instance, both Ember and Rails value convention over configuration - the goal is to get up and running apps quickly without tonnes of minutiae. Both systems are also focused on meaningful urls and, more importantly, testing. With EmberCLI, testing is built right into the deploy process.
The Ember Rails Gem
This was the first attempt to get Rails and Ember to work together. It still uses globals and is mostly being maintained for Rails4. Brings together:
- API
- asset serving
- testing
- asset compilation
- generators
However, upgrading from a gem is hard, especially when we have changing Javascript files. Keeping rapidly-moving applications in-sync and up-to-date is really hard. If you started the project with one version of Rails or Ember, it was very painful to update all the architecture.
EmberCLI
This was the communities answer to bind the two architectures together and make the experience more cohesive.
EmberCLI uses Broccoli as build tool for rapid compilation and deploy. Additionally, it has command line testing capabilities right out of the box.
Upgradability is the main goal of EmberCLI, so now it has a command ember init that provides a guided upgrade blueprint used for tracking differences between Ember version.
At this point, it didn’t make sense for Ember to be completely combined with Rails.
Ember and Rails are now completely separated in the EmberCLI model. Each system is tested independently to allow each to specialize to their own strengths. By compartmentalizing the front-end and back-end, it allows us to be more flexible and helps avoid monolithic application growth.
The downside is that we lose the full-stack testing capability, and, because we are now maintaining two separate codebases, deployments become more complicated.
EmberCLI Rails gem
So we bring it all back around.
- Rails handles the API and Asset Serving.
- Ember handles the Asset compilation and generators.
- Both have integrated testing.
Future
The Ember community has backed EmberCLI as illustrated by the explosion of new commit to its repository since its announcement at EmberConf 2014.
The changes in Ember 2.0 is going to be drastic and breaking for 1.x Ember apps. Which means we’ll have to spend time upgrading the Rails backend as well. Again, we have the familiar problem with rapidly-changing frameworks - they keep changing!
While I think Rails will continue to be the backend of choice for Ember applications, I do not think that the EmberCLI Rails gem will be the best way to go. In the end, we are still reliant on a single combined solution to manage the differences between the ever-changing systems. I’m not sure how the EmberCLI Rails gem will handle the multitude of changes in the future, but I seems like upgrading each system separately grants more stability.