10 ms·

New MVC client side JavaScript framework - Serenade.js

95 points by lest 15y ago

haclifford 15y ago
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 https://github.com/sstephenson/eco), but that's standard html.
- jfirebaugh 15y ago
  I just released a port of Slim with embedded CoffeeScript: https://github.com/jfirebaugh/skim https://github.com/jfirebaugh/skim If you prefer HAML, check out https://github.com/9elements/haml-coffee https://github.com/9elements/haml-coffee
- secoif 15y ago
  Stylus is an excellent contender. http://learnboost.github.com/stylus/ 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 https://github.com/visionmedia/nib
  - jsavimbi 15y ago
    Stylus is for CSS, not HTML.
    - secoif 15y ago
      Oh wow, I remember looking at my post thinking: "something's wrong here, oh well." I actually meant Jade: http://jade-lang.com/ http://jade-lang.com/. Jade makes HAML look like a dogs breakfast.
      - jsavimbi 15y ago
        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 15y ago
        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.js https://github.com/gregwebs/hamlet.rb https://github.com/gregwebs/hamlet.rb
- jnicklas 15y ago
  You can use Serenade pretty much as a static template engine if you want to. It's quite small (9k), so not a huge dependency.
arnorhs 15y ago
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 15y ago
  It seems like *.js framework is the new "Hello World".
  - phillmv 15y ago
    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 15y ago
      I'd argue that we're in the third generation already.
      - phillmv 15y ago
        I don't follow the js world super closely. What would you say were the first two (rich client/single page framework) gens?
        jsavimbi 15y ago
        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.
cjkihlbom 15y ago
Implementation of todomvc in Serenade.js: https://github.com/elabs/serenade_todomvc/blob/gh-pages/js/app.coffee https://github.com/elabs/serenade_todomvc/blob/gh-pages/js/a...
jashkenas 15y ago
Whoa ... it's pretty cool to see bits and pieces of CoffeeScript's compiler (http://coffeescript.org/documentation/docs/grammar.html 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.coffee https://github.com/elabs/serenade.js/blob/master/src/grammar...). Fun.
- jnicklas 15y ago
  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 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
goblin89 15y ago
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.
phzbOx 15y ago
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 15y ago
  Thank you :) Glad you like it!
randall 15y ago
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.
xxiao 15y ago
next framework should be named "YAJF", yet another javascript framework
ozziegooen 15y ago
Another .js framework? Must be that time of week again
no-espam 15y ago
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.
nyrb 15y ago
Nice to see another JavaScript MVC Framework written in CoffeeScript. Almost like Spine.js (http://spinejs.com/ http://spinejs.com/) A new thing to try it out later, but I'll stay with Backbone.js for now.
prodigal_erik 15y ago
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 15y ago
  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.
wooptoo 15y ago
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 15y ago
  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.
- jnicklas 15y ago
  It doesn't really push towards classes and classical inheritance, you're free to use any object with the framework that you with, which is not the case with most other frameworks that I've seen. It does use them internally, but that's only because I like it that way, I don't want to push that view onto users of this framework.
arturadib 15y ago
You can achieve code compactness without CoffeeScript: http://agilityjs.com http://agilityjs.com
- jnicklas 15y ago
  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?
fingerprinter 15y ago
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 15y ago
  As someone who hasn't really explored client-side MVC yet, my impression is that Backbone.js is the clear leader at this point.
TimRR 15y ago
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.

95 points by lest 15y ago

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 https://github.com/sstephenson/eco), but that's standard html.

jfirebaugh 15y ago
I just released a port of Slim with embedded CoffeeScript: https://github.com/jfirebaugh/skim https://github.com/jfirebaugh/skim If you prefer HAML, check out https://github.com/9elements/haml-coffee https://github.com/9elements/haml-coffee
secoif 15y ago
Stylus is an excellent contender. http://learnboost.github.com/stylus/ 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 https://github.com/visionmedia/nib
- jsavimbi 15y ago
  Stylus is for CSS, not HTML.
  - secoif 15y ago
    Oh wow, I remember looking at my post thinking: "something's wrong here, oh well." I actually meant Jade: http://jade-lang.com/ http://jade-lang.com/. Jade makes HAML look like a dogs breakfast.
    - jsavimbi 15y ago
      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 15y ago
        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.js https://github.com/gregwebs/hamlet.rb https://github.com/gregwebs/hamlet.rb
jnicklas 15y ago
You can use Serenade pretty much as a static template engine if you want to. It's quite small (9k), so not a huge dependency.

arnorhs 15y ago

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 15y ago
It seems like *.js framework is the new "Hello World".
- phillmv 15y ago
  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 15y ago
    I'd argue that we're in the third generation already.
    - phillmv 15y ago
      I don't follow the js world super closely. What would you say were the first two (rich client/single page framework) gens?
      - jsavimbi 15y ago
        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.

cjkihlbom 15y ago

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

jashkenas 15y ago

Whoa ... it's pretty cool to see bits and pieces of CoffeeScript's compiler (http://coffeescript.org/documentation/docs/grammar.html 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.coffee https://github.com/elabs/serenade.js/blob/master/src/grammar...). Fun.

jnicklas 15y ago
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 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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 15y ago

goblin89 15y ago

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.

phzbOx 15y ago

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 15y ago
Thank you :) Glad you like it!

randall 15y ago

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.

xxiao 15y ago

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

ozziegooen 15y ago

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

no-espam 15y ago

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.

nyrb 15y ago

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

prodigal_erik 15y ago

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 15y ago
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.

wooptoo 15y ago

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 15y ago
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.
jnicklas 15y ago
It doesn't really push towards classes and classical inheritance, you're free to use any object with the framework that you with, which is not the case with most other frameworks that I've seen. It does use them internally, but that's only because I like it that way, I don't want to push that view onto users of this framework.

arturadib 15y ago

You can achieve code compactness without CoffeeScript: http://agilityjs.com http://agilityjs.com

jnicklas 15y ago
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?

fingerprinter 15y ago

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 15y ago
As someone who hasn't really explored client-side MVC yet, my impression is that Backbone.js is the clear leader at this point.

TimRR 15y ago

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.