Imagine a Beowulf Cluster of JavaScript Frameworks

Actually Dustin's pull request is a bad example entirely. He wanted to change the whole API of emile. He liked the functionality but it didn't work for how he wanted to integrate it into ender. If an API doesn't work for you, you're kind of screwed, whatever library you're using. You either hack it yourself or you ask the maintainer. If some API of SproutCore wasn't to your liking, then what?

Dustin could've written an adapter around emile to expose the api he wanted to for ender. But that would defeat the purpose of ender which is to cleanly integrate several great micro frameworks. He didn't have to wait for Thomas. He wanted to explicitly. It was a goal of his to keep the dependencies pure.

Dependency hell is a problem with integrating several different frameworks. But I'm not sure this is the best illustration of that.

I started out working on a fairly complex dynamic form builder for the research group I work for. They needed a way to build up forms to administer to possible research subjects. The rest of the app was using pieces from jquery-ui so I stuck with that and added backbone.js to handle more of the complex interactive tasks. All of it was written in coffee-script.

Early on this approach worked fine and for simple CRUD stuff it's not too bad but as the researchers wanted more and more options it got difficult to sync everything; dom interactions, model data and server data. I started to investigate SproutCore and thought "This object model with bindings is just what I need!"

So, I'd really like to disagree with your comment, but I can't. The reason is because I can't integrate SproutCore with anything else that's been written for our app. I can't even get access to some of SproutCore's pieces to try and integrate it. The entire view part of our app would have to be re-written using SproutCore to use the features and that isn't viable right now.

As it stands, I'd really like to use SproutCore. There are some great ideas there and I think that some of my projects would really benefit from their projects. But right now, backbone.js + jquery-ui has hit the sweet spot of easy to get up and running and looks good. The researchers are really happy with what I've got done and I'm able to move on to other problems.

As co-creator of the NOLOH Framework (http://www.noloh.com) it's crazy for me to constantly read these posts, clearly we don't do a good enough marketing job. One of the benefits of NOLOH is it's lightweight and on-demand nature, that everyone in this thread, and in the blog post seems to be requesting, but without actually identifying it.

In the case of NOLOH, lightweight and on-demand means that the server sends the client only the necessary highly optimized client-side code for their application specific to the user's device at that current point in time, resulting in faster initial and continued loads. Similarly, as the user continues to use the application, NOLOH continues to send only the necessary and optimized code. This eliminates the fat-client problem, as the user only has what they absolutely need, specific to them. Similarly, in the case of search engine robots, NOLOH sends standards compliant semantically rich content, without the other baggage.

This is accomplished by implementing different renderers for each target device, so rather than use a general client-side library that loads everything it could possibly need for all browsers and situations, NOLOH has specific variations for each browser, version, and device. The ever growing number of browsers and devices demands this.

In "Lightweight, On-demand, and Beyond" in this past November's issue of php|architect, http://www.phparch.com/magazine/2010-2/november/ (sorry for the pay-wall, we'll repost it this month as the exclusivity period expires), we go in-depth explaining the next version of our lightweight and on-demand functionality, where we make it easier for us to maintain an ever growing number of target devices, while sending even better code to the client, without any drawbacks on either the client, or the server.

It's been very interesting reading all the posts regarding event-driven programming, fat-clients, and unnecessary bloat. I remember initially thinking about these issues in 2005 when Philip Ross and I first created NOLOH, we were young and naive at the time and like all good solutions, didn't have the status quo entrenched in our thinking. So when I read these posts and they have the same gist as our initial white-papers it saddens me that we haven't made as much progress as I thought we would've, it also makes me feel old.