

New MVC client side JavaScript framework - Serenade.js - lest
https://github.com/elabs/serenade.js

======
jashkenas
Whoa ... it's pretty cool to see bits and pieces of CoffeeScript's compiler
(<http://coffeescript.org/documentation/docs/grammar.html>), broken out and
reused for Serenade's template language
([https://github.com/elabs/serenade.js/blob/master/src/grammar...](https://github.com/elabs/serenade.js/blob/master/src/grammar.coffee)).
Fun.

~~~
jnicklas
I really love CoffeeScript. I hope you don't mind I… borrowed… some parts. It
was hugely helpful, especially since I'm quite new to writing parsers and
lexers. I put attribution in the README and the license file, in case you
missed it.

------
ryanfitz
I would avoid even trying this framework out because its written in
coffeescript. I have nothing against cs and write most of my clientside app
code in cs, but I think libraries should avoid using it. Simply because it
makes debugging more complicated. It adds in an extra step or 2 every time you
see a js error, you need to read the compiled code and then figure out where
that is actually coming from, from an unknown codebase (your framework/lib).

~~~
jeswin
1\. CoffeeScript produces very readable JS. Not the same as handwritten, but
close enough.

2\. This is a framework. You are less likely to be debugging into it, unlike
your own client-side libs written in CoffeeScript (which you mention doesn't
bother you).

I don't agree with avoiding a library because it is written in CS.

~~~
ryanfitz
When I am trying out/learning a new library or framework, I do a lot of
tinkering, looking around and reading the source code. Coffeescript output is
definitely readable, but you need to take a tiny bit of time to translate the
coffeescript output, to the actual source so you can read it, checkout the
comments etc to understand how you are supposed to do something. This added
bit of time adds up quickly for me.

For example when I was first learning backbone, which is only around 1000
lines and very well documented. I was constantly reading the source code to
understand why something wasn't working for me or how to implement something.
Projects typically aren't nearly as well documented as backbone, making
understanding the sourcecode even more essential.

~~~
Scriptor
If you're just reading the source of the framework, why not just read the
Coffeescript source instead of reading the generated Javascript code?

~~~
johncoltrane
Because Coffescript doesn't work in the browser, JavaScript does.

------
phzbOx
I'm never tired of seeing new MVC js framework. I feel like there are still
lots of improvement to be made. About serenade, I appreciate the simple
object/arrays for models and also the innovative templating with bindings.
(Instead of writing them in the html).

~~~
jnicklas
Thank you :) Glad you like it!

------
arnorhs
I don't really understand or appreciate what makes this framework better than
something like Backbone, Spine or Sproutcore.

Or to put it in another way: What problem does this solve that
Backbone/Spine/Sproutcore don't solve as well?

~~~
jpeterson
It seems like *.js framework is the new "Hello World".

~~~
phillmv
No, no, those are todo list apps.

Besides, we're still in the first to second generation of js rich client
frameworks. All this crazy amount of experimentation is _great_ ; it'll settle
down more towards the fourth to fifth generation.

~~~
jsavimbi
I'd argue that we're in the third generation already.

~~~
phillmv
I don't follow the js world super closely. What would you say were the first
two (rich client/single page framework) gens?

~~~
jsavimbi
I would cite early attempts at JS-generated views that I worked on in the late
'90s/early '00s (and I assume other people were doing similar things at the
time) and the various RIA frameworks that appeared on the scene circa '04-'05
spawned by Ajax that through no fault of their own tried to rediscover widget-
based portal solutions in JS. See Flex, Laszlo and others. Also tried was XUL,
all very limited and one-sided.

What we're seeing today is are mostly front-end MVC solutions that have a more
populist approach towards platform and usability as those two have matured
substantially due to the current global propagation of a certain genre of
apps. I hate to admit it, but Facebook has done wonders in terms of providing
feedback as to how much a user will tolerate beyond static HTML as well as
educating the user to accept as standard certain classes of JS functionality
as they iterate through implementations.

------
wooptoo
It baffles me how developers keep pushing for classes and classical
inheritance in JS, since it's clearly not how it was meant to be used. Why not
play to the language's strenghts instead?

~~~
jashkenas
That's really not the case. If you know how to use JavaScript's prototypes --
the "prototype" property and constructor functions -- you'll find that you're
using them in precisely the way that's best described as a class.

Developers are just calling a rose a rose.

------
goblin89
Very nice! Looks like Backbone.js turned into a framework with batteries
included and in-template event bindings.

I think it would make more sense to liken Serenade to Brunch, a kind of
framework based on Backbone. Serenade certainly looks promising in comparison.

------
fingerprinter
I am quite literally at a loss. I want to do something in Node with an MVC JS
framework, but there seem to be hundreds of them. There is no clear front
runner and that has to be hurting uptake.

So, what is the #1, #2 and #3 out there and where should I be spending my (not
enough of it with two kids) time these days?

~~~
mjor
As someone who hasn't really explored client-side MVC yet, my impression is
that Backbone.js is the clear leader at this point.

------
haclifford
Doesn't seem particularly game-changing.

I do like the haml style templating though, anything like this exist
standalone with coffeescipt not js syntax?

We currently use eco (<https://github.com/sstephenson/eco>), but that's
standard html.

~~~
secoif
Stylus is an excellent contender. <http://learnboost.github.com/stylus/>

I'd vouch it makes haml look like someone took stylus code and spat random
characters all over it. It's even got its own compass equivalent, nib:
<https://github.com/visionmedia/nib>

~~~
jsavimbi
Stylus is for CSS, not HTML.

~~~
secoif
Oh wow, I remember looking at my post thinking: "something's wrong here, oh
well." I actually meant Jade:

<http://jade-lang.com/>.

Jade makes HAML look like a dogs breakfast.

~~~
jsavimbi
You sir, are correct in that. Slim also merits a looking at, but I write
everything [static] in Jade first and then transfer the output to whatever,
yeah, JSP's. There's a significant performance hit from using non-HTML at run
time, +40% in some cases, as was Haml back a couple of years ago. Probably a
good reason why RoR adopted Sass yet shied away from Haml.

~~~
gregwebs
The Ruby slim templates get compiled to an intermediate language (Temple).
That is then compiled into an end form and everything is cached - the
performance is all the same.

RoR didn't pick Haml because Haml abandons HTML. Take a look at the Hamlet
language which give the best of both worlds.
<https://github.com/gregwebs/hamlet.js>
<https://github.com/gregwebs/hamlet.rb>

------
TimRR
This is just what the doctor ordered, for me. Been searching for a lightweight
pure framework that plays nice with other mobile app dev frameworks. Looks
like something I can wrap my head around. Someone mentioned it earlier, this
got just as much to do with mental models.

------
nyrb
Nice to see another JavaScript MVC Framework written in CoffeeScript. Almost
like Spine.js (<http://spinejs.com/>) A new thing to try it out later, but
I'll stay with Backbone.js for now.

------
cjkihlbom
Implementation of todomvc in Serenade.js:
[https://github.com/elabs/serenade_todomvc/blob/gh-
pages/js/a...](https://github.com/elabs/serenade_todomvc/blob/gh-
pages/js/app.coffee)

------
randall
Like. I think this feels more sparse than I'd expect, which is a good thing.
Not going to switch from backbone right now though, but I appreciate the
experimentation.

------
prodigal_erik
We have a responsibility to provide server-side rendering accessible to the
rest of the web. Can Serenade.js do this? The existing examples are all
broken—no content whatsoever without running custom code at the client.

~~~
jnicklas
It can, kind of. Though you will probably have to re-render on the client to
get all the events to attach. See the section about express.js support at the
bottom of the README (I haven't pushed it to npm yet, so you won't be able to
install it, fyi). Other web frameworks aren't currently supported.
Theoretically it's possible, though not very convenient.

------
ozziegooen
Another .js framework? Must be that time of week again

------
arturadib
You can achieve code compactness without CoffeeScript:

<http://agilityjs.com>

~~~
jnicklas
That's a very cool framework, I hadn't seen it. Thanks for the tip. Feels like
they have a lot of similar ideas to mine. Not really sure what Serenade has to
do with CoffeeScript though?

------
no-espam
Some advice on views, returning DOM nodes is not performant. DOM insertion is
costly. Consider a view representing a message in a chat room or tweets. What
if you want to insert 1000 messages in to a parent view? Building all the
messges in a string is much faster than inserting a DOM element for each
message. Google jsperf and see how badly the jquery template engine performs
which is based on DOMs versus micro-templating.

------
xxiao
next framework should be named "YAJF", yet another javascript framework

