Lots of interesting topics in Jonas' post worth discussing ... to pick a few:
> I tried to follow the Smalltalk-80 style of MVC very closely
> in Serenade.
Aside from ideological purity, did you notice any other benefits from sticking more closely to the Smalltalk-80 style? Personally, I can't imagine the benefit in "clearly defining the role of the controller as only reacting to user events" in a JavaScript app -- that's pretty much a single line of jQuery to listen for DOM events, and then call the appropriate method on the model. Having the same object responsible for rendering DOM elements also be responsible for listening to events on them seems much more useful.
> 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.
This distinction seems entirely academic, as in the documentation, you show:
var model = {};
Serenade.extend(model, Serenade.Properties);
... effectively ignoring the prototype chain by copying properties instead, but achieving the same effect.
> I came to the conclusion that doing this is only really
> possible by writing a purpose built template language.
[...]
ul#comments
- collection @comments
li @title
Do you worry about the constraints that are entailed by tightly coupling a logic-less template language to your framework? Whenever I talk to folks that are trying to use logic-less templates to build big apps, they
always seem to run into dead ends where being able to call a little bit of arbitrary code would make their templates so much easier -- whether it's zebra striping a table, checking the length of the array you're rendering, or what have you. To that extent, things like Handlebars provide escape hatches from Mustache's purity, with "registerHelper".
> Serenade has no dependencies. It achieves everything it
> does by using normal DOM manipulation.
Take care, as "normal DOM manipulation" is one of the slowest possible ways to build and render a UI. Do you have any benchmarks looking at how a Serenade template performs versus a more traditional innerHTML-based template of the same view, in, say IE7?
> 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.
[Applause]. Thanks for putting that in your post -- JavaScript's standard prototypal inheritance as practiced with constructor functions is just a longer way to say "class".