Hacker News Reader

Comment by nirvana | Hacker News Reader

Ok, I found this to actually be pretty useful. In reading the comments it cleared up a spot where my understanding of javascript was a bit weak.

More seriously, though, there seems to be a new javascript framework every day... and at some point I'm going to need to pick one for the project I'm working on. Its hard to tell which ones are appropriate for servers, vs clients, etc.

I wonder if anyone has made a directory of javascript frameworks?

I'm not looking forward to the task of going thru all the ones I've bookmarked over the past few months and trying to decide which are most appropriate, and which overlap each other, vs. which provide separate functionality that could be used together.

View on HN

Totally agreed about yearning for a directory of JavaScript frameworks.

I use a little jQuery, and I'm getting to the point where I'm ready to add a little more structure. But should I be using Backbone.js? Spine claims to be cleaner, but how do the communities/plug-ins compare? How does KnockoutJS compare? BatmanJS? Should I be abandoning jQuery for something more extensive like SproutCore or Sencha?

I'm also totally unclear on how compatible things are. A lot of the frameworks don't even seem to agree on basic things like how to do inheritance or whether they should use JavaScript or CoffeeScript. (Though I suppose they mostly don't break each others' namespaces any more.)

Is there some over-arching list of features that covers all of the existing frameworks, and that could be put into a table? If so, does such a table exist? If things are just a popularity contest, who is winning the popularity contest?

You should dig around, ignore claims of cleanliness or ease of use, read a little source code, and see which one floats your boat.

One way to get a good idea about how useful these frameworks are in practice is what's being built with them.

(I work on Backbone.js) You can take a look at the sort of apps folks are coming up with by scrolling through here:

http://documentcloud.github.com/backbone/#examples

... keeping in mind that Backbone hasn't even been out in the wild for a year yet, at this point.

There is a pretty nice list of JS libraries here: http://www.everyjs.com/

A company I work with uses ext.js, it's not open source (unfortunately) but I'm pretty impressed with what those guys can achieve with it and how long it takes them.

Thanks for the downvote, whoever it was. If you have had a negative experience with ext.js or think it is not an appropriate candidate it would be nice to know.

I've used ExtJS and while its a bit heavyweight for many typical sites, if you're building a very rich complex UI it can be very powerful.

Where it really excels is in support for IE6-8 - all of their controls, code etc just works, which is a godsend if you need to support these browsers.

Ignoring this "joke"; If you're looking for a light-weight MVC framework, try Backbone.js. It's rather nice.

I've never used it, but Backbone has a router which struck me as being completely out of place. In practice is it actually a good idea?

For rich client apps, having a router is useful in my experience. I've not used backbone however. What makes you think it seems out of place?

Router is integral for doing RESTful right.

Backbone may be lightweight, but that's only because it's a "framework" for exactly what the authors happened to be doing at the time. If you don't have a collection of objects as a JSON document at /some-url and each object available at /some-url/id, then Backbone does approximately nothing.

A simple reimplementation without http support looks something like:

    Model.prototype.set = function(key, value){ this[key] = value; for(v in views){ v.refresh() } }

    View.prototype.set_model = function(model){ model.views.push(this) }

    thing = new Model();
    view  = new ViewSubclass();
    view.set_model(thing);
    thing.set('foo', 'bar'); # WOWZA THE VIEW UPDATES!!!11!!!

While I decided not to use backbone, there is a need for a more structured encapsulation and abstraction of functionality.

For example, if the architecture you'd like to build only serves JSON and HTML templates, and javascript renders the rest, you save a lot on bandwith and cpu. The html is cached in the browser, the server only needs to produce JSON. Add a JSON based, restful DB, and you have an architecture that really fits what the web is becoming.

The JSON layer is perfectly suited for being the API layer other clients as well - otherwise you might have a lot of crufty code on the server that has to be cleaned up for use by any other client (e.g. native iPhone).

BTW - I believe the author of ligament also contributes to http://www.sproutcore.com/ and jQuery

There's this directory of libraries, but I think it's meant to exclude the larger frameworks: http://microjs.com/

Reply on news.ycombinator.com