abstract image of ryan

Welcome to ryanwold.net

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.

After 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.

My 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.