Ember.js: Attacking Boilerplate Where It Lives. Yehuda Katz.
A framework for creating ambitious web applications.
Ember is an (in my opinion) more experimental attack at the end-to-end problem. -@jashkenas
Data Binding is the core, the scaffolding of Ember.js
Data-bound declarative templates.Tell it what your model is and attach it to your view. Rather than have more layers of abstraction in Ember.js, every object knows how to do data binding.
In Backbone, the view class can be thought of as a kind of controller.
In Ember, the controller acts as the anchor-point between the multiple views and models.
- ORM on the client side
- Identity mapper on the client always returns the same object
- Indexing to lazy load object in the query and populate it later, mostly in the infrastructure layer rather than query layer
- Adapter layer is separate from model layer
- Ember has a REST adapter
Goals of Ember.js
- Identify common patterns and make them identifiable
- Manage complexity (if your app is complex you’re Doing It Wrong)
- Opinionated framework to make you more productive (addressing the problems that are a waste of time to have a conversation around)
- Optimized for developer happiness
Ember.js not a throwaway project, not a corporate backed product. It is built by and for the Ember community, an open source project first and only.
- Computed properties
- Massively improved debugging console output to log
- Can use names in conventions
- Post object can map to /posts
- Single rich object model
Characteristics of Ember.js View layer:
- Data Bound. Data binding is hierarchical and automatic. As the state of the object changes, Ember.js makes sure the DOM is updated and consistent.
- Asynchronous. Respects intermediate state. Ember will wait until everything else in the chain has finished before propagating. Transactions become atomic without any additional work. Don’t have to worry about multiple rendering.
- Declarative. Manages view hierarchy, parent and child views. It is naive to make child views and handle them with a closure or something. If you use #view in Ember, the hierarchy is built out automatically.
- Composable. Inject contents of templates.
- Customizable. Code to run when an element is inserted.
- Templates. Named templates and template API.
- Stateful. No state is stored in DOM. The view manages the state.
Basic app architecture
- Models provide data to controllers, controllers provide data to views
- Views trigger events on controllers, controllers modify models
- Models update controllers, controllers update views
- Models contain persistable data
- Controllers proxy models and add client side app state
- Views represent a single representation of app state
Evolving patterns and where Ember is headed
- Evolving patterns with the goal to roll in where they fit.
- Routing: sproutcore-routing, port of old SproutCore routing system, planning on official routing solution
- State managers: undocumented, used internally, pattern for how to use it is not clear
- Persistence: getting better through ember data
- Improved debugging: because of the declarative nature, it is hard to hook in for debugging. A debug build could provide more information, at the cost of slower performance. Working on a Chrome extension.
- Documentation: sparse and needs more info on common patterns that are not encapsulated in code
- Rails integration
- As patterns solidify Ember rolls them in
When people can’t agree on a pattern, sometimes we give them a little push