Ember.js #throneofjs

Yehuda Katz (@wycats) gave an overview of Ember.js — Tom Dale is expected to dive into code today at the Throne of JS Conference in Toronto.  Below are my rough notes as a almost-live blog the conference,

Lots of people are making small frameworks. Few frameworks are trying to solve the problem of creating full applications

Ember’s Influences:  Sproutcore, Rails, jQuery, merb (Rails 3)

Lessons from Rails

conventions are good

  • don’t need to spend time on trivial decisions
  • shared solutions are good — bugs get fixed faster, more people know the answers to common problems
  • solutions should look the same

extraction is better than pie in the sky ideas

  • modularity is good, but the best kind of modularity is hidden from regular users (example ActiveModel)
  • clean internals important for ongoing velocity
  • shipping is more important than perfect code

Lessons from jQuery

  • dealing with browser quirks sucks
  • repeating yourself sucks
  • you get a lot of leverage from shared solutions
  • keep as many people on the same path, climbing up the same mountain

Lessons from Sproutcore

The Good:

  • bindings
  • declarative
  • computed properties
  • application structure
  • cocoa?  learn from people who have been creating UI frameworks since desktop was new

The bad:

  • Hard to Learn
  • Coupled to UI Toolkit
  • Massive File Size (was hundreds of K, ember is <40K)

Key learning: We’re not trying hard enough (to make great Javascript frameworks).  We’re not aiming high enough.

What do people love about it?

  • data binding (almost every framework except for spine & backbone) Ember’s sophisticated system is “sane by default.” It solves pathological cases.  For example: mark all done, when binding to every item in a collection, summary display is only calculated once)
  • View Layer: lets you focus on what is special about your views, not the boilerplate
  • Composable: real apps don’t dump everything in index.html
  • Setup & Teardown: sucks to manage your own memory, browser does it well, but if you have your own objects, which we all do, ember helps with that
  • Events

Other highlights
Make classes, not instances

The Router is awesome

  • defines where specific actions are legal, let you create islands of functionality
  • URL serializes application state
  • routes are automatically associated with templates, via naming conventions


  • data managerment without the boilerplate
  • URL -> JSON -> identify map -> model attrs
  • dirty records -> toJSON -> REST
  • decomposes gracefully

Data Adapters encapsulate persistence concerns: don’t let the vagaries of your backend dictate how your application works

  • find, findAll, findMany
  • save, CRUD
  • serialize to/from JSON

Lots of committers, not just Tilde.  Tom Dale and Yehuda work at Tilde.  They are doing consulting where they build apps that require a sophisticated framework like Ember.  They plan to keep doing that to fund the open source work, and to continue to grown the committers so that Ember is a true open source community project. They don’t plan to roll out a paid support biz model.

 Future, onward to 1.0

  • expect breaking changes before 1.0, not after
  • lots more docs
  • server-side rendering