Blog


Jan

Why Serenade.js?


Yesterday I opened up the repo for Serenade.js to the public, and discussion ensued on Twitter and Hacker News. A lot of people are asking why we would need yet another client side framework, so I thought I would write down why I think Serenade offers something we haven't really seen yet.

MVC

A lot of the popular client side frameworks today claim to follow the MVC pattern. But the way the MVC pattern was originally envisioned is very different from what any client side MVC framework is doing today. This paper outlines the MVC pattern used by the Smalltalk-80 interface, developed at Xerox PARC. It's that old, and still very relevant.

The paper outlines the responsibilities of the MVC triad as follows:

Views: Present data from the model and update it if it changes, notify controllers of user interaction events.
Controllers: React to user interaction events by instructing the model to perform certain actions.
Models: Handle business logic and persistence, notify the view of any changes to the data.

A notable difference to how most MVC frameworks today handle this is that it is often the controller's responsibility to present data to the view, and make sure that that data is up to date, giving the controller much bigger responsibility than it would otherwise have. Oftentimes the controller is also responsible for rendering the view, and as in Backbone, for placing it in a particular location on the page.

By clearly defining the role of the controller as only reacting to user events, we can isolate it from a lot of concerns. We are following the single responsibility principle, and as an added bonus, we've made it possible to test our controllers without even involving the DOM.

I tried to follow the Smalltalk-80 style of MVC very closely in Serenade. The almost unexpected side effect of this was that neither models, nor controllers needed any kind of special logic. In Ember.js for example, all objects you want to use inherit from Ember.Object. In Serenade you can use any JavaScript object as a controller or a model, which means you can use it in an existing application or in just a fragment of an application without having to bend your entire app around it.

Templates

The template language in Serenade.js is very carefully constructed so that binding data to both attributes and text is possible, without a lot of additional code in the templates, and without any additional markup. Consider the following example:

h1[title=@name] "His name is " @name

The resulting markup from this would look like this:

<h1 title="Jonas">His name is Jonas</h1>

No additional markup at all! And yet, when I update name to "Peter", the markup just magically changes to this:

<h1 title="Peter">His name is Peter</h1>

And it does this without changing anything that doesn't need to change. The text "His name is" for example is not affected at all by this update.

I came to the conclusion that doing this is only really possible by writing a purpose built template language.

Let's look at this:

ul#comments
  - collection @comments
    li @title

Which would generate something like this:

<ul id="comments">
  <li>Hello</li>
  <li>Awesome</li>
</ul>

Just adding another comment by pushing it onto comments post.comments.push({ title: 'It works' }) would append it at the end:

<ul id="comments">
  <li>Hello</li>
  <li>Awesome</li>
  <li>It works</li>
</ul>

With no additional markup, with nothing explicit needed to make this dynamically update. It's all simple, clean and efficient. Without writing a custom template language this would simply not have been possible.

In contrast, frameworks like Ember and Batman need to add a lot of additional markup for similar functionality, and it's much more difficult for them to do these kinds of things without unexpected side effects.

jQuery

I'm not a huge fan of jQuery. It does what it does very well, and I use it on a majority of projects, but sometimes I want to use something else. I really intensely dislike the fact that pretty much all client side frameworks depend on jQuery. It stifles innovation because it makes it impossible for competitors to have a chance. I wanted to use MooTools for a project recently. It would have been a better fit. But I couldn't, because my framework forced me to use jQuery, and I didn't want to use more than one library.

As far as I can see, Batman is the only framework that is usable without jQuery, using Batman.Solo. Kudos to the Batman.

Serenade has no dependencies. It achieves everything it does by using normal DOM manipulation. This means we probably have to give up on ever supporting IE6, since it has too many weird quirks to work around, but all other browsers in use today, yes even IE7, work without needing a lot of tweaking.

And as an added bonus, if you are using jQuery, just call Serenade.useJQuery() before rendering any views and Serenade will use jQuery for event bindings, instead of its own custom code.

Clear point of entry

In the end we want to use frameworks client side to dynamically manipulate the DOM. I found that most frameworks didn't start at this point though. There are routers, controllers, dispatchers, and all other kinds of things that you would need to add in order to actually get to the point where DOM nodes are created.

Serenade turns this whole concept on its head. We start off by generating DOM nodes. No routers, no dispatch, nothing. Just render a view and insert it into the DOM:

var element = Serenade.view('h1 "Hello world"').render();
document.appendChild(element);

Want to put some data into this?

var model = { name: 'Jonas' }
var element = Serenade.view('h1 "Hello" @name').render(model);
document.appendChild(element);

As you can see you can use Serenade like a template engine. In fact you could use it together with a framework like Backbone, just to render templates. You could specify your Backbone views as the controller in Serenade, and bind events from the view. Cool stuff. Serenade is extremely flexible in how you can use it, and that's because it has a single, simple, point of entry.

Small

Serenade is just 9k gzipped, so it doesn't require a huge download. By comparison, Ember is 37k gzipped. That's more than four times the size! Plus it depends on jQuery, which is another 31k.

But aside from being small in file size, Serenade is also small in concept. It tries to solve one single problem, abstracting away DOM manipulation, and very little else. The model layer abstractions it provides are just helpers to simplify the communication between models and views.

The one other feature Serenade provides is caching, which I've found to be incredibly hard to implement and maintain, and really wanted the framework to take of for me. Transparently and automatically caching stuff in local storage is a huge win, especially for mobile applications.

JavaScript-y

Some of the comments on HackerNews complained about the use of CoffeeScript and especially its classes. I think that's kind of unfair. Serenade is written in CoffeeScript and internally makes a lot of use of CoffeeScript classes. But you're not forced to use them in your application at all.

Let's first clear up that CoffeeScript classes are nothing else than fancy syntax for JavaScript's prototypal inheritance, and the fact that they are called classes, is just calling them what prototypal inheritance is used for in 99% of cases.

As I mentioned before, you can use any JavaScript object with Serenade. The first few examples in the README show how to extend regular JavaScript objects with Serenade.Properties, so that you can get dynamic view bindings without using any constructors. This was very important to me. I didn't want to force people to use constructors if they didn't want to. I didn't want to impose how to create objects at all. Using Serenade.Model is definitely the path of least resistance, but you don't have to use it if you don't want to.

I think that Serenade is a lot more conservative in pushing you towards a class-based way of writing your apps than any framework currently out there. Maybe this doesn't come across very well in the documentation, I'll happily accept suggestions for improvements.

Testability

Unit tests are still unpopular in JavaScript land, but for those that do love them, Serenade makes it incredibly easy to test your application logic. Since templates are logic-less, unit testing them is unnecessary. Instead you can focus on testing controllers and models. Since neither of them interact with the DOM at all, you don't need the DOM to test them, which means you can test them completely in isolation. That's a huge advantage.

Conclusion

Serenade is not radically different from other options out there, I am well aware of that. But the devil is in the details. I hope that people who have had experience writing Backbone or Spine apps or have used other frameworks, will appreciate how simple Serenade is, and yet how it solves a lot of problems which are incredibly annoying and difficult and tedious to solve otherwise. It's not a revolution, it's an evolution.

Nov

Our Presentations at RubyConf 2010


Two weeks ago, Jonas and I were in New Orleans for the 10th annual RubyConf. This was my 2nd RubyConf, but I had a very different experience this time. This time I was one of the speakers. And I was giving two presentations.

The Front End Testing Frontier

One of the presentations was an extended version of the Front End Testing Frontier presentation I gave at Mountain.rb in October. This time I was fortunate enough to have my colleague Jonas Nicklas as a co-presenter. Jonas is the author of the testing libraries Capybara and Evergreen, our primary tools for JavaScript testing at Elabs.

I've uploaded the slides from the Front End Testing Frontier presentation, but they're pretty sparse. Video should be available in a few weeks, and I'll update this post then.

Socialist Software Development

My other presentation was titled Socialist Software Development. I came up with the title after seeing a clip from The Daily Show about socialism in Sweden. I saw some similarities between the principles of socialism and agile development, and since it seems most Americans are terrified by the mere mention of socialism, I thought it would be fun to go to the US and talk about it. The essence of my talk came from this passage from the British Labour Party constitution:

The Labour Party is a democratic socialist party. It believes that, by the strength of our common endeavour we achieve more than we achieve alone, so as to create, for each of us, the means to realise our true potential, and, for all of us, a community in which power, wealth, and opportunity are in the hands of the many, not the few.

While I drew some inspiration from my flippant title, I mostly talked about how Sharing is Caring, and how important that is in software development.

Giving such a "soft" talk was quite a bit harder than giving a technical presentation, but I was very happy with how it went. I've posted the slides for the Socialist Software Development presentation as well, and I'll update when the video is online.

What's Next?

I've been to a lot of conferences this year, and it's been great presenting at Mountain.rb and RubyConf. The next conference on our schedule is the Scottish Ruby Conference in April next year. All the Elabs developers will be there, and I'm really looking forward to that. Then there's our own conference, Nordic Ruby, in June. This year was amazing, and it looks like the one next year will be even better.

I don't have any confirmed speaking events for next year, but I would love to do a couple and continue to improve as a speaker. But I think I'll limit it to one presentation per conference. Giving two at RubyConf was a bit overwhelming.