Ember.js brings some new and interesting conventions to the table for designing single page applications. In this talk, I'll be covering the key pieces of Ember, how it compares to other frameworks, and the backstory of why it was created.
2. Who am I?
• Aaron Ortbals
• Full-stack developer at Chaione
• @aaronortbals
• me@aaronortbals.com
3. What is Ember.js?
A client-side javascript framework used for building complex web
applications
4. The Creators
• Tom Dale @tomdale
• worked on Sproutcore framework at Apple and the MobileMe/iCloud
applications
• Yehuda Katz @wykats
• rails core contributor
• heavily involved in open source
• Ember core team is 8 strong
5. Tilde
• Tom andYehuda co-founded Tilde, a product & consultancy company
with Carl Lerche, and Leah Silber
• Heavily focused on open source
• Team members contributing to jQuery, Rails, Ember, Bundler...
• Tom andYehuda met through Sproutcore and a startup called Strobe
7. Circa 2005...
What was the web was like in 2005?
• IE 6
• jQuery was coming next year
• And along came server-side web application frameworks like Ruby on
Rails and Django
9. Provide a better experience with JS
• Many studies have shown that latency can significantly impact usage
• You can cache but page reloads require re-parsing, executing CSS & JS,
etc...
• To improve latencies, many sites have moved to Single Page Applications
10. Give us a backbone
• In late 2010, when Backbone.js was released, a lightbulb
went off in a lot of people’s heads
• It’s fast, light-weight, and very easy to jump into
• But what if you want (need?) more?
13. The Ember Philosophy
• Ember favors convention over configuration
• Ember forces you to do things correctly from the start
• When you use it you might notice similarities to Cocoa and Rails
14. Conventions
• Strong conventions are really meant to help when you are a team of
more than one
• When a team member adds a new feature, it shouldn’t break old
features
15. Designing the Ember API
• The team was very focused on getting the API correct pre-1.0
• Led to breaking API changes which pissed people off
• It is all about taking use cases and constraints and designing an API
that will work the best given those constraints
16. Why did I pick it?
• I really like the structure (especially for large apps)
• The core team is very good and I like the roadmap
• I’ve been highly productive after I crossed the chasm
• While definitely not required, Ember works very well with Rails
17. Benefits
• Fully featured
• They really care about URLs
• Good community, vastly improving docs
• Once you grok, developer productivity can be very high
18. Disadvantages
• Still young, but we are close to a 1.0 release (1.0-RC6)
• Backbone,Angular, and others are more mature, less risk
• Development of Ember-testing is trailing the API
• Ember-data is not 1.0 (what is Ember-data?)
19. What’s Coming for Ember?
• Focused on documentation and the 1.0 release
• Continued work on Ember-testing and Ember-data
• Working with the standard’s bodies to plan for and incorporate the
next generation of JS
20. • Traditional SPAs do all their rendering on the client
• What about indexing?
• Hybrid rendering is the future
• Both the client and the server can render the page
• Ember has an up-and-coming solution to this with Handlebars
The Problem
23. Templates
• Ember uses Handlebars which wraps {{things}} in curly braces
• You can do things like
{{#linkTo post}}Welcome to Ember!{{/linkTo}}
• or
<ul>
{{#each model}}
<li>
{{partial 'posts/show'}}
</li>
{{/each}}
</ul>
24. Template Helpers
Build a helper when you want to present data in a specific way.
Handlebars.registerHelper 'fullName', ->
person.firstName + " " + person.lastName
<span class="name">{{fullName aaron}}</span>
Use it like:
25. Views
• A view translates events in your template to events that have meaning
to your application
• Typically only written in cases where you want to handle complex user
events or create reusable components
click Delete Controller Router
deleteItem
is deleteItem here?
27. Ember Data
• Ember Data is a library that is designed to:
• make it easy to retrieve records from a server
• make changes in the browser
• save those changes back to the server
• Think of it as providing facilities similar to what an ORM does on the
server
• Works with Rails out of the box if it follows the
active_model_serializers gem’s conventions
28. Getting Setup with Ember Data
• store.js.coffee
• Remember, Ember Data is pre-1.0, so watch for breaking changes
App.Store = DS.Store.extend
revision: 12
29. Models
• Models work well with Ember Data, but can use any persistence layer
• A model looks like this:
• Find a user:
App.User = DS.Model.extend
firstName: DS.attr('string')
lastName: DS.attr('string')
email: DS.attr('string')
username: DS.attr('string')
user = App.User.find({ name: "Aaron" })
30. Relationships
• A model can have relationships. Look familiar?
App.Request = DS.Model.extend
name: DS.attr('string')
user: DS.belongsTo('App.User')
filled: DS.attr('boolean')
createdAt: DS.attr('date')
updatedAt: DS.attr('date')
31. Ember Data Alternatives
• Ember-Model - extracted from a live application by core-team
member Erik Bryn
• Ember-Resource - from Zendesk
• Others: Ember-RESTless, Emu, Ember-REST, JQuery directly
32. Router
• Ember.js represents each of the possible states in your application as a
URL
• Or the user hits the back button
• Avoid losing state when the user uses traditional navigation
View
interacts event
33. Wiring up some routes
• Static routes
• Resource routes
• Nested resources
• Use the browser history
API (no hash bangs!)
App.Router.map (match) ->
@route 'app', { path: '/'}
@route 'login'
@route 'signup'
@resource 'users', ->
@route 'new'
@resource 'user',
path: ':user_id'
@resource 'requests', ->
@route 'new'
@resource 'request',
path: ':request_id'
# Use the browser history API
App.Router.reopen
location: 'history'
34. A Route
• Each route has a route handler
• It finds the model, hands it to the controller, then renders a bound
template
App.UsersRoute = Ember.Route.extend
model: ->
App.User.find()
App.UsersNewRoute = Ember.Route.extend
model: ->
App.User.createRecord()
App.SignupRoute = App.UsersNewRoute
35. Controllers
• Models have properties that are saved to the server, while controllers
have properties that don’t need to be saved to the server
• In other words, anything that is specific to the current session
App.UserController = Ember.ObjectController.extend
delete: ->
if (window.confirm "Are you sure you want to delete this user?")
@get('content').deleteRecord()
@get('store').commit()
@transitionToRoute('users')
An Example User Controller:
