Yehuda Katz: Ember.js State of the Union

Yehuda Katz (@wycats) was speaking to Glasgow.js, these are my notes from his talk.

Ember.js State of the Union

Where they are and where it's going.

Ember exists because there was a gap in JS frameworks - some were huge, some were tiny. Key principles were taken from other frameworks:

From Rails

• Conventions are good
• Shared solutions are good.
• Solutions should look the same
• Extraction is better than pie in the sky

From the merb and Rails merge

• Modularity is good (especially when hidden from casual users)
• Activemodel (decoupled but tightly integrated)
• Clean internals are important for ongoing velocity
• Shipping is more important than perfections

From jQuery

• Browser quirks suck
• Repeating yourself sucks
• You get leverage from shared solutions

From Sprout core

The good:

• Bindings - declarative
• Computed properties - declarative
• Application structure
• File system (see Ember-Rails for an example)
• Cocoa

The bad:

• Hard to learn
• Coupled to UI toolkit
• Massive file size
• Cocoa

We're not trying hard enough!

JS application frameworks aren't trying hard enough to overcome constrains.

What do people love about ember?

• Data bindings
  • Sophistication (sane by default)
  • Don't immediately propagate changes to the DOM
• Views
  • Sophisticated (focus on what is special about your views, not the boilerplate)
  • A little does a lot
  • Garbage collected to limit memory leaks
  • Composable (real apps don't dump everything into index.html)
  • Setup and teardown (managing your memory gets tiring)
  • Events (Don't wast brain cycles deciding how to wire a click event to a method on your view.)
  • We think about it so you can focus on your app logic.

Bringing it all together

• Singletons and testing. No longer use singleton controllers.
• Make classes, not instances (when Ember boots your app it will make sure all your objects have the dependencies it needs).
• Routes. Ember has its own router that manages serialisation as well as state.
  • Route declaration is nested to match URL structure.
  • URL serialises application state (with conventions, automatic and error free). Can reverse from a model.
  • State in the router maps onto a template rendered via a controller and a view.

The Future

• 1.0!
• Docs, Docs, Docs
• Performance (Correctness first, performance second)
• Server-side rendering - SEO, performance and less capable clients
• Better error handing
• Local caching - use client side storage before hitting the server.
• Git model for records - roll back records. Uses a git model for branching data locally before merging back. Can be used to delay updates to the UI until the changes to the model items have been committed and merged.
• More official adaptors
• Extended attributes

Adaptors - Data management without the boilerplate

Should be able to get persistence with several side frameworks (Rails, Django) This is handled by adaptors

How do you? - These questions should be answered for you by the framework,

• Determine which URL:
  • To load from
  • To commit to
• Extract data
• Preload or lazy load
• Serialisation
  • foreign key or embed?

Data model is:

• server
• transaction
• record

It decomposes gracefully. If you only need to change how your data is serialised to JSON you can do that. This is all handled in the adaptor. Find, CRUD, serialise to JSON, materialise from JSON.

Encapsulate the persistence concerns. Don't let the vagaries of your backend dictate how your application works.