From 9b3745ff41a45eac49644f1b4434b9fb123c10cb Mon Sep 17 00:00:00 2001 From: José Mota Date: Fri, 17 Aug 2012 01:22:58 +0100 Subject: Post: The quest on Ember.js --- _posts/2012-08-16-the-quest-on-emberjs.markdown | 184 ++++++++++++++++++++++++ 1 file changed, 184 insertions(+) create mode 100644 _posts/2012-08-16-the-quest-on-emberjs.markdown (limited to '_posts/2012-08-16-the-quest-on-emberjs.markdown') diff --git a/_posts/2012-08-16-the-quest-on-emberjs.markdown b/_posts/2012-08-16-the-quest-on-emberjs.markdown new file mode 100644 index 0000000..128f1dc --- /dev/null +++ b/_posts/2012-08-16-the-quest-on-emberjs.markdown @@ -0,0 +1,184 @@ +--- +layout: post +title: The quest on Ember.js +tags: [ development, ember, javascript ] +published: true +--- + +> `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](http://emberjs.com) as a strong alternative to +[Backbone](http://backbonejs.org) 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. + +Lately I've been watching some videos on Ember and reading the guides over in +the tool's website and I must say I'm intrigued. Unlike Backbone – which is +more of a library –, Ember stands as a full MVC Javascript framework, and when +I say _full_, I mean it covers all the letters in the acronym and it does the +job in a slightly different way than we're used to. I'm writing down the sum of +my learning experience thus far so bear with me. : ) + +Controller: Stateless vs. Stateful +---------------------------------- + +All the hype on MVC is scoped to server-side, stateless frameworks like Rails, +Spring, Laravel, Play!, Django and [many +more](http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features). +The `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. + +Model: Persistence +------------------ + +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 `AJAX`, +preferably using something like [Ember.Data](http://github.com/emberjs/data), a +plugin that allows you to create persistable objects in your app. It's based +around `REST` so it should be easy to integrate with a Rails app or any other +framework that supports `REST`ful `URL`s and `JSON`. + +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 +development. + +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 +more. + +View: DOM integration +--------------------- + +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 `HTML` +result. It might have a little Javascript to manipulate the DOM to an extent +but it will end up performing stateless requests to the server in order to +retrieve/send data. + +### Backbone's Views + +The `View` class in Backbone was built to have power over the DOM's events with +the `events` option: + +{% highlight javascript %} +var TodoView = Backbone.View.extend( + render : function () { /* generate markup */ } +, events : { + "click .mark-complete": "mark-complete" + , "change .body" : "update-todo" + } + +, mark-complete : function () { /* your code */ } +, update-todo : function () { /* your code */ } +); + +new TodoView({ + model : myTodo // instance of Backbone.Model +}); +{% endhighlight %} + +This example has: + +* A `render` method which ideally generates the markup. You can use something + like [Mustache](http://mustache.github.com) or + [DoT](http://olado.github.com/doT/) to generate the markup and jQuery to + manipulate the `DOM`. + + The actual content to be put on the page is not this view's responsability + but another parent view or collection. + +* An `events` option 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. + +* All the methods defined in the `events` option. + +Notice that you pass a `Backbone.Model` instance when creating a new view. + +### Ember's Views + +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](http://handlebarsjs.com)-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. + +#### Create a view + +1. Create a Handlebars template in the page (don't worry, it won't be visible + in the browser): + +{% highlight text %} + +{% endhighlight %} + +2. Create a View object in your app: + +{% highlight javascript %} +App.TodoView = Ember.View.extend({ + change: function() { /* update object */ } +}); +{% endhighlight %} + +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 +value. + +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. + +So I have a question for you. +----------------------------- + +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](http://en.wikipedia.org/wiki/Pomodoro_Technique) 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?_ -- cgit v1.2.3-54-g00ecf