New MVC client side JavaScript framework - Serenade.js(github.com)
github.com
New MVC client side JavaScript framework - Serenade.js
https://github.com/elabs/serenade.js
53 comments
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...). Fun.
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.
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).
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.
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.
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.
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.
If you're just reading the source of the framework, why not just read the Coffeescript source instead of reading the generated Javascript code?
Because Coffescript doesn't work in the browser, JavaScript does.
[deleted]
I'm very glad you posted your comment. It's a reasonable view and the one that I wanted to respond to.
To the author: I don't think you should rewrite this in JavaScript if you like CoffeeScript. I think you should write all of the examples in your README in CoffeeScript. I don't think you'll draw interest from people who aren't open to CoffeeScript, at least early on. Those who are already using CoffeeScript or are curious (I'm somewhere between the two) will prefer all the examples to be in CoffeeScript.
Besides that, there is some overhead in switching between reading the two languages. I was wondering why there were so many parens when I hit the first couple JavaScript examples.
To the author: I don't think you should rewrite this in JavaScript if you like CoffeeScript. I think you should write all of the examples in your README in CoffeeScript. I don't think you'll draw interest from people who aren't open to CoffeeScript, at least early on. Those who are already using CoffeeScript or are curious (I'm somewhere between the two) will prefer all the examples to be in CoffeeScript.
Besides that, there is some overhead in switching between reading the two languages. I was wondering why there were so many parens when I hit the first couple JavaScript examples.
I went kind of the opposite way and rewrote the initial example in JavaScript. I'd really prefer if people didn't get hung up on the fact that it's CoffeeScript, I don't think it should matter too much to people using the framework what language the internals are written in.
Unfortunately, it is an issue if you're not a regular CoffeeScript user yourself. If you're making significant use of any framework, at some point you're going to have to dive into the internals and figure out how it works or why is isn't working the way you expected.
With a CoffeeScript project, you either have the choice of reading code which wasn't generated with humans as its target audience, or code which actually expresses the author's intent, but using a language you don't normally read or write, which comes with its own bunch of constructs and idioms which you need to be able to transpile on the fly in your head to understand.
In that case, gods help you if the author has gone overboard on CoffeeScript's Rubyisms or used @ in a particularly esoteric way.
With a CoffeeScript project, you either have the choice of reading code which wasn't generated with humans as its target audience, or code which actually expresses the author's intent, but using a language you don't normally read or write, which comes with its own bunch of constructs and idioms which you need to be able to transpile on the fly in your head to understand.
In that case, gods help you if the author has gone overboard on CoffeeScript's Rubyisms or used @ in a particularly esoteric way.
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).
Thank you :) Glad you like it!
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?
Or to put it in another way: What problem does this solve that Backbone/Spine/Sproutcore don't solve as well?
I don't know, but reading through this framework gave me an instant, "I can use this in my current project" feel that Backbone/Spine/Sproutcore didn't. As someone else pointed out it's not so much about solving different problems or solving problems better, as solving problems in a way that feels more natural to your problem and style of programming.
It seems like *.js framework is the new "Hello World".
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.
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.
Ha! indeed, todo apps are the new hello world. Regarding the .JS frameworks, I actually think it's a good thing that many are being created, this grows the community and the need to solve problems in different ways, more ideas, feedback, etc.
Check this review of the most popular MVC frameworks, http://goo.gl/2VhZX
I actually wrote a todo list app as an example (https://github.com/elabs/serenade_todomvc), I'm going to go hide now ;)
All these frameworks make me think of this XKCD:
http://xkcd.com/927/
http://xkcd.com/927/
I'd argue that we're in the third generation already.
I don't follow the js world super closely. What would you say were the first two (rich client/single page framework) gens?
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.
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.
Ha! When I saw the headline I did think "MVC Frameworks are the new Todo List app". I knew someone would say something to that effect. :)
That said, the amount of effort in these frameworks is admirable and pushes ideas and best practices forward.
That said, the amount of effort in these frameworks is admirable and pushes ideas and best practices forward.
Good point, I wrote up a blog post explaining why I wrote Serenade. I don't feel that it solves any new problems, but it solves existing problems in a different way. Check it out! http://elabs.se/blog/33-why-serenade
It's not about solving a problem. It's about solving the same problem slightly better. The reason why new MVC frameworks pop up all the time is because everybody organizes and writes their code differently based on their own use cases and mental model of how things should work.
There is no ubiquitous JS MVC framework because to be honest, either the APIs out there are not very good or it's too much overhead to simply pick up and use for a beginner in many cases.
There is no ubiquitous JS MVC framework because to be honest, either the APIs out there are not very good or it's too much overhead to simply pick up and use for a beginner in many cases.
I don't think it makes sense to compare this to Backbone.js, which is more of a library than framework.
it's "super pretty"
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?
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.
Developers are just calling a rose a rose.
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.
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.
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.
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?
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?
As someone who hasn't really explored client-side MVC yet, my impression is that Backbone.js is the clear leader at this point.
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.
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.
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.
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
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
Stylus is for CSS, not HTML.
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.
http://jade-lang.com/.
Jade makes HAML look like a dogs breakfast.
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.
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
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
I just released a port of Slim with embedded CoffeeScript: https://github.com/jfirebaugh/skim
If you prefer HAML, check out https://github.com/9elements/haml-coffee
If you prefer HAML, check out https://github.com/9elements/haml-coffee
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.
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.
Implementation of todomvc in Serenade.js: https://github.com/elabs/serenade_todomvc/blob/gh-pages/js/a...
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.
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.
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.
Another .js framework? Must be that time of week again
You can achieve code compactness without CoffeeScript:
http://agilityjs.com
http://agilityjs.com
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?
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.
next framework should be named "YAJF", yet another javascript framework