Post: The quest on Ember.js

1 files changed, 184 insertions, 0 deletions

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 %}
+<script type="text/x-handlebars">
+  {{"{{#view App.TodoView" }}}}
+    <input type="text" {{bindAttr value="body"}} />
+  {{"{{/view"}}}}
+</script>
+{% 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?_