Chain.JS + JavaScriptMVC turn offs

[Justin Meyer]

I noticed on twitter that someone posted they weren't crazy-super in-
love with JavaScriptMVC and I inquired why. Their response:

"Biggest issue? I like chain.js style data-binding via attribs (e.g.
HTML5 data-*) more than using a template language."

I really appreciate feedback! It's great when people who don't like
your stuff let you know why. It's an opportunity for improvement.
But twitter is the worst place to send messages back and forth. I'll
post my response here because other people coming to JavaScriptMVC
might have similar feelings.

First, JavaScriptMVC makes it really easy to integrate with any
template. It does play nicest with EJS because you get a few more
features. But Micro, Jaml, Mustache, and jquery-tmpl are all
integrated with $.View and stealjs's build system. It's pretty
straightforward to add any other template type.

So, tossing away all the other great things that JMVC provides for
your choice of view when we've spent so much time making View work
with any template language breaks my heart. I suppose we haven't
release view yet so this might explain a little.

But the choice of Chain.js (http://wiki.github.com/raid-ox/chain.js/)
is especially interesting.

By the looks of it, a page using Chain.js comes with your templates in
the form of DOM elements, and you fill the content in. This has 2
serious drawbacks compared to EJS and the other template languages
that JMVC supports:

#1 performance.

innerHTML is WAAAAAAAAAAAAAY faster than iterating through and
updating the DOM. I've used EJS to draw 1000s of rows in IE6. It
freezes a tad during the insert. But this is orders of magnitude
faster than going through the DOM.

#2 organization+maintainability

I think this is a big problem. Consider some functionality to show
the result of a new purchase order. Presumably, with Chain.js, you'd
have to first insert the HTML of your template into the page then fill
it in. Well, this wastes time of course, but where do you get that
HTML from?

Do you hide it in hidden elements when the page loads? I hate that.
This is what lot of templating solutions want you to do and it's plain
stupid. How do you maintain this and share this across apps? How do
you load it on demand?

I suppose you could have a list of client side templates the server
maintains as partials that you can include into your final HTML. But
it seems very wrong having the server deal with this stuff.

But even if you do that, you're left with 2 insert cycles. The first
to add the elements (via innerHTML), the second to fill them out.


I could be wrong on all of this. I don't know chain.js. It seems
like a nice tool if you're building websites with very little use of
templates and where performance isn't important. It also as an upside
in that it forces you to use similar className - propertyName pairs.
EJS doesn't do that but there are template languages that do.

Anyway, let me know if I am missing something. The more feedback the
better.

[Ed Toro]

Hey Justin.

Cool that you took the time to ask and respond to some Twitter
feedback like this.

Performance:
Agreed. I suspect it's just an implementation detail. I haven't
looked into it, but I suspect you can maintain the API (DSL?) that
chain.js presents and have it do innerHTML instead of DOM updates
behind the scenes. But that's not the reason why I like it better.

Org/Maint:
I appreciate your well written description of the 2 insert cycles. A
template language would be probably be good for inserting new partials
into a page, which wasn't a case I had thought about. I was thinking
of an empty template being generated in the server with future updates
coming in the form of JSON AJAX requests that data-bind into the
template.

So, even if you may think it seems wrong to have "client-side
templates" generated in the server (maybe?), those are just the
limitations of the use case I had in mind.

Backing up for a moment, the reason why I think the chain.js pattern
(if not the implementation, granted) is more attractive is that it
just makes more sense to me to semantically annotate my HTML markup
(via id/class tags or HTML5 data-* attribs) than to construct it
through a separate template language. I'm turned off to view template
languages in general. It feels like a conflation of view &
controller.

So what feels right to me? My MVC background is with Rails and Adobe
Flex frameworks like Cairngorm. I think data-binding in ActionScript
feels right. ActiveRecord feels right. And controllers... that's a
long story.

p.s. After watching functional inheritance in Crockford on Javascript
Act III, the "Simple Class" inheritance pattern looks awkward, but it
might just take some getting used to.

[Justin Meyer]

Thanks again for the feedback. Hopefully I can again draw you into
more specifics.

But first, on this view thing ....

I think organizing templates with the server is wrong, but more
importantly, it's unwieldy for the server to send the HTML of your
page along with hidden templates for JS. It just doesn't scale. And,
I like my concerns separated.

What do you use on the server to make html? I don't know of anything
that provides Chain.js style templates.

I like the idea of Chain.js, just not its performance, and that pretty
much the most important thing to users ever ever ever. I'd be
interested in a templating language that looked like chain.js. It
would be pretty easy to write. It would take a string, parse it to
XML, and then convert it to a JavaScript function. This could have
the important performance characteristics of other Template languages,
but have Chain.js's "forced" symantics.

Plus, the symantics aren't ChainJS's best feature. It's that it's
just HTML. You would still have to learn new rules, but you could use
a lot of existing html tools.


Now one statement I am very suprised you made:

"It feels like a conflation of view & controller. "

I don't know how joining strings of with data is a mix of V and C.
There's no querying the page or models for extra data. My gut feeling
is that you might be used to PHP style DB queries in the top of a php
page. If you want complete protection against this, you might check
out: http://github.com/edspencer/jaml


I assume you are talking about JMVC's class:
http://jupiterjs.com/news/a-simple-powerful-lightweight-class-for-jquery
when you say "Simple Class" is awkward.

What's awkward about it? Is there something else that has similar
functionality that you find easier?

Thanks again for sharing. Keep it rolling.

[Ed Toro]

I think there might be some confusion over the word "template". When
I say that the server is generating a "template", I mean that the
server is generating a fully-structured HTML page, not a partial. I
use "template" to mean that the whole page looks like this (adapted
from the chain.js page):

<html><head/><body>
<div id="quickdemo"><div class="item"><span class="library"></span></
div>
</body></html>

Rather than this:

<div id="quickdemo">
<div class="item"><span class="library">Name1</span></div>
<div class="item"><span class="library">Name2</span></div>
<div class="item"><span class="library">Name3</span></div>
</div>

That is to say that the structure of the page is returned, but the
actual data (e.g. the Text Nodes) are not. Those come later, after a
request for JSON and some data-binding to conveniently named classes.

{[{"library": "Name1"}, {"library": "Name2"}, {"library": "Name3"}]}

Since the page is "empty" (in a sense), then the server in this case
doesn't have to be an application server, but instead a simple file
server that returns the "template" plus the JS/AJAX code necessary to
initially populate that template and subsequently update the data
without going back to fetch more HTML. Perhaps there's some logic to
resolve URL routes or swap JS includes, but other than that, since
there's no data, there's no need to touch controller/model code in the
server when returning this initial structure.

I'm still in agreement that the "innerHTML" insert cycle would be more
efficient if the HTML you're "inner'ing" isn't being generated by an
application server but is simply being fetched from a file server,
rendered (if you've fetched a template that requires rendering to
HTML), and then populated with data. I'm still thinking in terms of
the other insert cycle, where there's really only one "template" (the
whole "empty" HTML page) that needs to be populated with data (e.g.
Text nodes). Correct me if I'm wrong because otherwise I'm having
trouble understanding what you mean by "organizing templates with the
server" and fetching "hidden templates" that represent separate HTML
partials (or full pages, if you're trying to avoid page loads?).

The chain.js semantics that I dig come from this:

$('#quickdemo').items([
{library:'Prototype'},
{library:'jQuery'},
{library:'Dojo'},
{library:'MooTools'}
])

Which, to my mind, means an HTML/CSS-only designer can create a well-
annotated HTML structure with no data in it and I can write pure
controller and model Javascript to populate data into that structure
without me or my designer having to learn a new templating language.
That division of labor represents a good separation of concerns to
me. All I need to know is that 'quickdemo' represents some kind of
container that contains elements annotated with "library" that I can
attach text nodes to. All my designer needs to do is make sure there
aren't multiple or unexpected 'quickdemo' declarations in the page.

This, on the other hand:

<ul>
<% for(var i = 0; i < tasks.length; i++){ %>
<li class="task <%= tasks[i].identity %>"><%= tasks[i].name %></
li>
<% } %>
</ul>

Looks to me like an HTML dev paired up with a JS templating dev to
write view code, which smells like conflated View/Controller logic to
me. (JAML looks like this to me as well, btw.)

Speed? I still think you can data-bind the JSON data using innerHTML
if you'd like.

Regarding the JavaScript "Class" abstraction, I just defer to
Crockford on that. My interpretation of his lecture is that JS
doesn't have "classes" for a reason, and making it look and feel like
a "classical" language masks some of the good things in JS, like
closures and functional composition, which may be harder to understand
at first, but better represent what JS "is" rather than what we'd like
it to be. But, again, it just looks awkward to me in that context. I
can't think of a way to objectively defend my impression. Whatever
works for you.

Also, I'm pretty sure Crockford refers to the speed difference between
innerHTML and DOM manipulation in JS to be "in the noise" with respect
to page load time as compared to the big things like rendering the
DOM, fetching pages, and fetching data, but don't quote me on that.

Ed

[John Hardy]

Yes assuming that I am understanding you correctly, a "template" is a complete HTML page which has been mocked up by a designer. In theory it shouldn't even need to be completely empty. In fact it would be better if it was was mocked up with phoney data so that everyone could see what the populated page looks. 

The mockup page would annotated with classes ids and data attributes which map to the view logic. But the designer should be able at any time to take the mockup back and work on it without disrupting the work of the programmer. That is a real separation of concerns.

Iteration and conditional logic would not need to be explicitly defined. If a div representing a row was mapped to an object it would populate the row using class names as keys. If it was mapped to an array of objects, the div would be repeated and mapped to each array item.

Not sure if thats what chain.js is about but there's my ideal of a templating system. ;-)

No logic, no special syntax. Just pure HTML that a designer could create and maintain.

--
You received this message because you are subscribed to the Google Groups "JavaScriptMVC" group.
To post to this group, send email to javasc...@googlegroups.com.
To unsubscribe from this group, send email to javascriptmv...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javascriptmvc?hl=en.

[Justin Meyer]

Thanks again ed.  

If Crockford said that innerHTML vs DOM are approximate he's very wrong.  Just like how he thinks we should completely stop on HTML5.

We're talking 2 ish orders of magnitude.  This is real time, potentially measured in seconds, your users will wait around.  I've had templates take a second to compile.  Anything with the DOM takes much much longer than raw JS manipulations.  

Crockford can't defend his position either.  This is why YUI has http://developer.yahoo.com/yui/examples/yahoo/yahoo_extend.html .  There are 2 problems with javascript's native prototypes:

1.  People don't understand them.  Most people who think they do, really don't.  Every time I give my prototypes talk, even the most experience people are like, oh no way ...

2.  They break easy.  Go ahead and put code in that constructor function.  Just wait until someone tries to inherit that.  If you don't understand what I'm talking about, see #1.

JS doesn't lack classes because it doesn't need them.  They tried to add them with JS2 / ECMA4.  This thankfully got destroyed for good reason.  It's not because having classes wouldn't be nice.  It's because JavaScript is designed to be as easy of a language to implement as possible.  Once you understand prototypes, you'll realize its a great way of getting as much functionality as possible out of as little 'language' code and features.  This is why JS took off. It took MSFT less than a few months to put together a near perfect copy of the language (JScript).  

Adding classes would be a mistake by the language designers.  But, it's absolutely necessary if you're building something big and want people to be able to use that functionality without too much hassle.  

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com

[Justin Meyer]

John,

  Yeah, that would be pretty sweet.  Chain.js is not that.  Maybe something for 3.1.

Ed,

Correct me if I'm wrong because otherwise I'm having
trouble understanding what you mean by "organizing templates with the
server" and fetching "hidden templates" that represent separate HTML
partials (or full pages, if you're trying to avoid page loads?).

Ok, I think we have rather different application life-cycles.  I care more about performance than anything else.  I always try to get the page to load with initial content.  But also, my pages are applications.  They last a long time and add new content dynamically.  I don't know what might happen with my page.  I could send the page down with a bunch of hidden templates.  To do this, I would have to make changes in the server code every time JavaScript needed a new template.  This is in contrast to EJS and such which allows you to create a template in say 'foo.ejs' and render it like:

$("#new_bar").html('foo.ejs',{ ... });

That way the JS team can work completely independent of the server.  I just need a public folder.

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com

[Ed Toro]

I think John hits the nail on the head with his comment. The reason
why I think he's right is the "view" code on the chain.js GitHub page
is just regular HTML and the "controller" code is the data-binding
logic (although he doesn't refer to "view" and "controller" in the
docs). http://wiki.github.com/raid-ox/chain.js/

It looks like my ideal templating language as well. :) Am I reading
too much into chain.js?


Performance:
Seems like if the chain.js implementation could be changed to use
innerHTML this wouldn't be a problem any more. You could ask "raid-
ox" about that.

Also, Crockford admits innerHTML is faster, but if you're seeing 2x
orders of magnitude, I'd have to wonder whether, in your benchmark
test, you're adding each child to the main document on creation (which
generates a render after every append) or if you're building a subtree
and adding it all at once (which only generates a render at the end).

"If you say I'll put a node into the tree, and then put its child on
the tree and so on, and build it from the top down, that's really
slow, because each time you add one of those nodes you may pay for
another re-flow. Whereas if instead you build the thing independently
from the bottom up, and then plug the whole thing in when you're
finished, it's one re-flow, so that'll go a lot faster."

"... all of the browsers implement innerHTML even though no standard
requires it. It raises a question for the developer: which one should
you use? If you're making new content to put into a page, should you
build each of the nodes individually and paste them all together and
plug them in, or should you build up a big text and use innerHTML to
do that?
My advice is, do the one that favors clean code and easy maintenance
for your application. This is, in most cases, something that should
not be decided in terms of performance. Performance should only
influence you in extreme cases. In ordinary cases, if performance is
not going to be undermining the user experience, choose the one that
makes the most sense. If performance is an issue then you want to use
innerHTML, because browsers are really good at that. Even though it
appears that the browser's doing a lot more work, it goes a lot
faster."
-Crockford Episode 4

There's some subtlety in there which leaves room for you being right
and wrong at the same time. Right in that innerHTML could be 2x
orders of magnitude faster, but wrong in the sense that it may not
matter.

I'm not sure if I want to belabor this point any more because it seems
like quibbling over implementation details. Performance questions
always have an objective answer. Just test it and find out what's
best for you.

I also think "how you want to do OOP in JS" is an implementation issue
as well. I imagine if I really wanted to use Crockford-style
functional inheritance in JavascriptMVC, I could, even if everyone
else thought it was a bad idea. Framework flexibility is a good
thing.

You don't have to respond to every criticism to defend JMVC's honor.
Sometimes we can just agree to disagree.

The main issue is view template languages. And I think you're right
that we have very different application life-cycles in mind. My use
case is a lot smaller than yours, so the optimal solution is probably
different. If I wanted a full application in the browser, with
multiple differently structured partials that render in and disappear
out of the page or full page reloads replaced with JS-initiated full-
page DOM updates, the page would be a lot heavier and would require a
different organization. I think a separate templating language might
be appropriate there.

But if, for example, I have a table with some data in it and a refresh
button, and all I want to happen on refresh it to fetch some data and
repopulate the rows of that table without changing the structure, then
calling out to a separate template language feels like too much when
compared to my "ideal templating system". Is there no room in JMVC
for locally optimized solutions? Or should I build my simple app as
if it could someday become a full-blown Flash-killer RIA that only
ever touches my app server for JSON strings?

Personally, I think my adoption would be easier if there were a way
for me to use bits and pieces of the framework for a single page in my
Rails site and ramp up to the full framework gradually over time.
That's part of the warm and fuzzy feeling I'm looking for in a JS MVC
framework. Chain.js gives me that feeling because it's small enough
that I can imagine playing with it in a single page and seeing how it
works without having to rearchitect my site. I have AJAX calls, I
have roughly annotated divs that get JQuery selected and populated
with the results of that call (usually HTML snippets into innerHTML).
Rails supports JSON APIs well. What if I replace this HTML injection
with a JSON data-binding? That's the inspiration.

ps. There are a lot of things I like about JMVC as well. I like
ActiveRecord-style (if you name your functions appropriately) models
that wrap simple data services. I like controller naming
conventions. I like directory tree conventions. And I like
frameworks that are opinionated.

On Sep 10, 2:59 am, Justin Meyer <justinbme...@gmail.com> wrote:
> John,
>   Yeah, that would be pretty sweet.  Chain.js is not that.  Maybe something
> for 3.1.
>
> Ed,
>
> Correct me if I'm wrong because otherwise I'm having
> trouble understanding what you mean by "organizing templates with the
> server" and fetching "hidden templates" that represent separate HTML
> partials (or full pages, if you're trying to avoid page loads?).
>
> Ok, I think we have rather different application life-cycles.  I care more
> about performance than anything else.  I always try to get the page to load
> with initial content.  But also, my pages are applications.  They last a
> long time and add new content dynamically.  I don't know what might happen
> with my page.  I could send the page down with a bunch of hidden templates.
>  To do this, I would have to make changes in the server code every time
> JavaScript needed a new template.  This is in contrast to EJS and such which
> allows you to create a template in say 'foo.ejs' and render it like:
>
> $("#new_bar").html('foo.ejs',{ ... });
>
> That way the JS team can work completely independent of the server.  I just
> need a public folder.
>
> Justin Meyer
>
> Jupiter Consulting
> \Development\Training\Support
> 847-924-6039

> justinbme...@gmail.com

>
>
>
> On Fri, Sep 10, 2010 at 1:46 AM, John Hardy <jhlag...@gmail.com> wrote:
> > Yes assuming that I am understanding you correctly, a "template" is a
> > complete HTML page which has been mocked up by a designer. In theory it
> > shouldn't even need to be completely empty. In fact it would be better if it
> > was was mocked up with phoney data so that everyone could see what the
> > populated page looks.
>
> > The mockup page would annotated with classes ids and data attributes which
> > map to the view logic. But the designer should be able at any time to take
> > the mockup back and work on it without disrupting the work of the
> > programmer. That is a real separation of concerns.
>
> > Iteration and conditional logic would not need to be explicitly defined. If
> > a div representing a row was mapped to an object it would populate the row
> > using class names as keys. If it was mapped to an array of objects, the div
> > would be repeated and mapped to each array item.
>
> > Not sure if thats what chain.js is about but there's my ideal of a
> > templating system. ;-)
>
> > No logic, no special syntax. Just pure HTML that a designer could create
> > and maintain.
>

> ...
>
> read more »

[Justin Meyer]

Ed, 

  Thank again for sharing your thoughts.  I'm not defending JMVC's honor.  I'm trying to highlight good development practices.  It's 2x the order of magnitude because you are not only walking the entire html structure of your template, you're doing multiple insertions.  Instead of 1 DOM operation, it's doing O(1+n+i) operations where 

1 - query to get all nodes

n - dom nodes to check

i - nodes that are modified (insertion). 

   You're right that building nodes from the bottom up is faster.  However, Chain.js does not do that.

  You're also right that it might not matter if you're doing very limited work with templates.  But why risk it?  You're not gaining much in the way of maintainability or development time using Chain.js.  I wouldn't provide it as the default choice of a framework b/c I want to keep people from hurting themselves.

  Imo, your optimized solution (of replacing the rows) is not optimized.  My guess is that with about 50 rows, you'd start noticing a lag in modern browsers.  In IE, it would be 1/2 a second.   

  But, it is possible to use pieces of JavaScriptMVC in any site as pretty much every part works without every other part.  JavaScriptMVC is entirely flexible.  You can download and drop in your page: controller, class, all the dom and special events.  Very soon you will be able to take its Model and View layers too.  You can also use StealJS (its dependency managment / build system) on its own.  And, you can use FuncUnit to test any application (even those w/o jQuery).  

  I guess we will have to agree to disagree on one point - the supremacy of performance.  I agree that you can go overboard with performance improvements that don't matter.  Look at FuseJS.  It will change:

ob = ob || {}

to 

ob || (ob = {} )

to save on one extra assignment.  But if you're building a prescription for people to write very solid apps (a framework) everything has to be fast, especially when it comes to prescribing DOM manipulations.  This is because users only really care about performance.  I will have to find this article by Nielson, but performance and security were tied for the most important features a website can have.  There's a summary of the importance of performance here: http://www.masternewmedia.org/why-website-speed-and-page-load-times-are-so-important-to-your-online-readers/ .  It's just plain interesting that the nicest looking design will never trump better performance.

Anyway, I'm very happy you keep writing.  It's helpful to engage people who don't think the same way.  I really like the idea of a fast performing ChainJS.  And, we'll do a better job of highlighting JMVC's flexibility.

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039

justin...@gmail.com

--

[Thomas Reynolds]

Not to derail this too far, but code speaks louder than words :)

I've built a proof-of-concept controller based on the Pure (http://beebole.com/pure/) templating library (which I like more than chain.js and is smarter about being fast).

http://github.com/tdreyno/javascriptmvc-pure

Basic usage looks like:

  Create a DOM element in your HTML:

    <div class="who"></div>

  

  Create a Controller:

    $.Controller.Pure.extend("MyPureController", {}, {});

    

  Initialize the Controller:

    $(".who").my_pure();

    

  Set the data:

    $(".who").controller(MyPureController).setData({ who: "It's me" });

  

  Notice that the div's contents have now updated to contain the text "It's me"

There are hooks and callbacks to integrate your model's into this so they can push new data to the controller. One limitation is that the "views" have to already exist in the DOM. There should be a way to autoload them from the server (and cache them) just like EJS templates, but I haven't looked at that yet.

I'm not sure if this is a good idea, but I'm intrigued by the concept. jQuery has a cool method of including a portion of a page requested via Ajax. I think it'd be useful to have essentially a "designed" widget library of blank, styled components. Then I could build widgets by combining that html, the pure controller and some JSON from my models.

Tell me what you think,

-Thomas

[BlessYAHU]

I like it and I like pure. No view tags, just html. It would be
great if there was something like this for server side. With env.js/
jsdom.js and node.js, I guess it wouldn't be too hard.

Concerning the limitation, could you load your view into a document
fragment, run pure against that, then inject into the dom?

> >http://www.masternewmedia.org/why-website-speed-and-page-load-times-a....

> >  It's just plain interesting that the nicest looking design will never trump
> > better performance.
>
> > Anyway, I'm very happy you keep writing.  It's helpful to engage people who
> > don't think the same way.  I really like the idea of a fast performing
> > ChainJS.  And, we'll do a better job of highlighting JMVC's flexibility.
>
> > Justin Meyer
>
> > Jupiter Consulting
> > \Development\Training\Support
> > 847-924-6039

> > justinbme...@gmail.com

> ...
>
> read more »

[Justin Meyer]

Yeah, that's still slow.  The best case is to generate a JS function like what EJS looks like when compressed into production.  You shouldn't touch the DOM at all to make string.

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039

justin...@gmail.com

> ...
>
> read more »

[Thomas Reynolds]

Pure has a compilation step that's cached after the first run, but generates a function exactly like you suggest.

Example: http://beebole.com/pure/documentation/recursion-example/

I don't have any problem with EJS in practice, but I do admit that writing for loops inside ASP tags feels a little icky.

-Thomas

[Justin Meyer]

Agreed.  Everyone has their favorite template language.  This is why I want JMVC to get out of specifying the template and instead making it possible to use any template in a uniform way.

So, I'm planning on making it possible to not pack the template language in production.  This will be available if you are compressing all your views into the build file (or now files).  This will mean that you can have an app comprised of several template languages, but process / compress to just the JS functions.  And, the template code can be as complex and big as you want it.

Cool huh.

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com

[John Hardy]

A compile step is all that is needed. These kind of coding styles should be compiled into a fast string based system using innerHTML and not use the dom. 

Performance does matter at the production phase but we do have more flexibility during the development phase. It would be great if they could be compiled into ejs templates at build time, so that there is no performance hit on the production version. That's something that a build-based system like JMVC can offer without breaking into a sweat.

Whether this approach is worth while on the client is yet to be proven. I have used a system like this on the server-side and I like it. It's a lot like using CSS and HTML but in reverse. The main thing I like is that there is no process in the workflow in which the designer has his design "templatized" in an irreversible way. The designer (who admittedly may well be the same person as the programmer) can work completely in parallel. The need for partial files scattered about is minimized and maintenance of the HTML can utilise all the best tools.   

[Victor Kornov]

Hey guys,

Chain.js looks a lot like http://knockoutjs.com/ to me. In a way that it allows data binding your JS objects to html DOM and display the data automagically. I'm not exactly sure how one would combine a knockout style programming model with strict MVC in JavascriptMVC though. But I really do like the databinding stuff.

Check it out. http://knockoutjs.com/