

Why Serenade? - jashkenas
http://elabs.se/blog/33-why-serenade

======
jashkenas
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".

~~~
jnicklas
1) Smalltalk 80 style design

The advantage is that the controller knows nothing about the DOM, so it is
usable and testable without the DOM. And while I agree that it's a single line
to add a binding, that quickly becomes a single line for every single event
you ever want to listen to. It ends up being a sizable amount of code. Aside
from that, it seems clear that binding data is best done in the view, not in
the model or controller, why are events different?

2) Using normal JavaScript objects

You don't _have_ to extend the objects with Serenade.Properties. The downside
is that data in the view isn't automatically updated. But as in the first
examples in the README, it's perfectly acceptable to send in "JSON" directly
to the view.

In the example right after the one you posted, I show how to add properties to
the prototype. The intent is not to sidestep prototypal inheritance, but since
multiple inheritance or mixins aren't available in JavaScript, copying over
the functions is as close as we can get.

3) Break out

I just realized that it's not documented in the README, I'll have to fix that,
but it's possible to add custom instructions. Any function added to
`Serenade.Helpers` is available as an instruction in the view. This is very
similar to handlebar's registerHelper. See the spec here:
[https://github.com/elabs/serenade.js/blob/master/spec/integr...](https://github.com/elabs/serenade.js/blob/master/spec/integration/custom_helper.spec.coffee)

4) Performance

I have not done any benchmarks, so honestly I can't say how it compares
performance wise. I'm not terribly worried about IE7. At the moment, we don't
even support it, and it'll be dead soon. We could possible use document
fragments to speed up the rendering, but I'm unsure if it actually makes a
difference. I would argue that Rails is slow, Ruby is slow, PHP is slow, Java
is slow, C is slow, etc..

~~~
jashkenas
1) Smalltalk 80 style design

Right -- you mentioned testing, but I'd like to hear more about benefits in
your actual app. Putting something in a separate object _just_ to make it more
"testable", but without any actual benefit to, or effect on your app's
behavior, strikes me as the essence of unnecessary abstraction. You can
certainly test views that "know something" about the DOM without actually
using the DOM as well...

4) View/Template Performance

Ok then, IE8. It has largely the same DOM performance characteristics (ie,
_slow_ ) as IE7 -- and it'll be around forever, or as long as Windows XP lasts
-- whichever comes first ;)

For the purposes of a web application, Rails/PHP/Python being slow matters far
less than your template library being slow. They're in the backend, you can
run many instances across many servers, you can cache their output, etc.

If your JS templating / View library is too slow, it means you _can't_ use it
to build the most interactive and interesting parts of your UI -- precisely
the parts for which using client-side views would be most helpful.

I'm talking about even relatively simple things, like this:
<http://blog.documentcloud.org/blog/2011/10/entity-charts/>

Better to benchmark now and find out, either way.

~~~
joliss
Jonas wrote: > The advantage is that the controller knows nothing about the
DOM, so it is usable and testable without the DOM.

Jeremy wrote: > You can certainly test views that "know something" about the
DOM without actually using the DOM as well...

I've been wondering for a while how to eliminate the slow and brittle Selenium
layer from integration tests (perhaps I'm not the only one?). I'm thinking
that if you can do away with the DOM, you might be able to somehow run the
integration tests on the server, without launching a browser.

Do you have any concrete ideas how to do this, or are you only talking about
unit tests in the text I quoted?

~~~
jnicklas
If you move most of the application client side, you could use something like
jsdom to test it. That's obviously not going to get you the same level of
confidence that a full stack test in a real browser would though. Maybe a
combination of the two?

------
danielmason
I'm sorry not to add value to the discussion, but I wanted to say the back-
and-forth has been a very educational look at some of the practical trade-offs
that framework designers have to make.

------
cjkihlbom
Original thread is here: <http://news.ycombinator.org/item?id=3529034>

The framework itself is here: <https://github.com/elabs/serenade.js>

------
fedesoria
Excellent post. Loved the framework's ease of use for people already familiar
to jQuery.

