TL;DR— I'm considering starting a series of screencasts on how to use Ember. Will you help me? Check the latest section at the bottom.
Disclaimer — I have only begun looking into Ember a couple of days and shamefully haven't typed any code yet. This writing invites feedback and enlightenment.
I've been suggested Ember as a strong alternative to Backbone in order to build heavy client-side apps. I tried Backbone in my spare time and it's awesome. However, I never had the chance to use it in a real-life situation so I never really put it to a stretch.
All the hype on MVC is scoped to server-side, stateless frameworks like Rails,
Spring, Laravel, Play!, Django and many
HTTP protocol's nature constrains the very controller's lifecycle and
purpose. A controller mediates the client and the server, providing a
representation of data that's stored in the latter and controlling the entire
logic of the application for a particular request.
If you're to use Ember.js, you need to purge that idea off your head because an Ember controller is not sovereign in a request scope. In fact there is no single request anymore, there's a bunch of tiny little controllers in a whole ecosystem that is your app which happens to be enclosed in a single page. These controllers live as long as you have the app running so they kind of become stateful and are used more than once during their lifecycle.
As of a regular webapp, requests are made to the server and content is sent back to the browser. We send forms to change the state of the app.
In Ember, all the communication to the server is done through
preferably using something like Ember.Data, a
plugin that allows you to create persistable objects in your app. It's based
REST so it should be easy to integrate with a Rails app or any other
framework that supports
You can still use regular
Ember.Object classes to materialize domain objects
in your app. That was the whole point from the beginning of Ember's
Persistence in Ember is actually a thing I find a bit more complicated than in
Backbone as the former requires a plugin, whereas the latter comes with
REST-based persistence built in. But again, I need to look into it a bit
The nature of a view is to provide a representation. It has the necessary power to capture the representation's events and do something about them.
In stateless server-side apps, the view has no power: it's just an
but it will end up performing stateless requests to the server in order to
View class in Backbone was built to have power over the DOM's events with
This example has:
rendermethod which ideally generates the markup. You can use something like Mustache or DoT to generate the markup and jQuery to manipulate the
The actual content to be put on the page is not this view's responsability but another parent view or collection.
eventsoption that specifies the events and the DOM element they affect, followed by the method to be called.
Typically you update your data through these methods which, by turn, might trigger other events in the whole app. You register those bindings yourself as you build the app.
Notice that you pass a
Backbone.Model instance when creating a new view.
One of Ember's base features is data binding. Not only do objects bind themselves but also the DOM stays updated by the same principle. If you make a change in an object, the Handlebars-powered views are instantly updated. Unlike Backbone, all the object to DOM binding is seamless and it just works. That might be the coolest feature they have, in my opinion.
Ember views come packed with a series of custom handlers that represent the
various DOM events. In this case,
change refers to when the input changed its
Even though this approach looks more complicated, there are features in Ember that make up for it. I still haven't delved deep enough but I noticed the particularity.
There are a lot of other reasons for me to stick with Ember for a while. I'm interested in knowing how statecharts and routing work. Also, the tightness and opinionated nature of the framework made me curious as to how much of the boilerplate is removed.
The title of this writing has a point.
I screencast often even though I don't bring that out too much. Anyway, I would love to record a series of videos (preferably with someone else) in the near future on this topic, one pomodoro at a time. All the process on design thinking, implementation and trial & error would be part of the videos. Would you be interested in joining me? Remember, the whole point of this is to develop a solution in the aspect of a rookie.
Screencasting is a hard job and it takes (a lot of) time. I'm facing a challenge in doing this as I consider Ember to be steep to learn, but enticing at the same time. Also, it seems there aren't many examples on how to implement an end-to-end application if ever so lightly. A sponsor would be a great incentive for me to rush things up and start sooner than I expect. Would you be interested in sponsoring the series?