I had the opportunity to use Ember on a project for most of 2015. The learning curve, moving from Rails 3.x & 4.x to Ember.js, was quite steep for me. Retrospecting, it was largely the common vocabulary between the frameworks that reference different concepts and data-flows.
Routes in Rails are similar, but different from Ember's Router and Routes.
Rails Controllers are short-lived, but Ember's Controllers persist through an application's loaded lifecycle.
Rails Models are duplicated for the most part on the client-side with Ember's models. Ember's Models can manage conventional has_many relationships easily, as well as client-side validation.
Rails Views and Ember Views are different. Rails views are rendered as html in the browser, in the same way that Ember's Templates are. In Ember, a View is a javascript file that contains (javascript) behaviors for a Template.
Ember has come a long way in the last 18 months or so. From 1.2ish to 2.x. Ember-cli has become the defacto way of building Ember apps; providing conventions for common patterns.
@Emberjs + @Firebase feels magical
— Ryan Wold (@randw) December 22, 2015After getting it up and running again in my local Sandbox, I took a stab at getting Ember-cli running with Firebase as an independent codebase. Within 10 minutes, I created this Ember Prototyping repository, created from ember-cli with emberfire installed.
3 small commits to get up and running with @Emberjs and @Firebase - https://t.co/48nAX2fRob
— Ryan Wold (@randw) December 23, 2015My hypothesis is that having a flexible, persistent data-store will be helpful for developing javascript-heavy apps, because a significant portion of javascript apps are developed in the browser development tools. Not having to coordinate restful services as an intermediary, out-of-browser code snippet becomes a win.