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

Ember.data

• 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