Alt Framework Hackfest

We here at IT appreciate the diversity of web frameworks and methodologies that have arisen or gained popularity over the last few years, and we've had our filthy paws over and into a few of them. Some we like more than others, and some of us are more vocal in our advocacy than others.

What I'd like to propose to my co-conspirators here is that we have a little hackfest with some of our favorite web frameworks over the next month or two, and see what develops. I'd propose some similar goal to be developed in each framework, but that might be too constricting. I'll let you guys weigh in before we kick it off, just to get consensus, but I'm guessing spinning out a blog in each shouldn't be too hard, and it would allow for embellishment as the frameworks and time allow. (note, I know we all have crazy schedules right now, which is why I think a month or two sounds good... correct me if I'm wrong)

Frameworks I'd like to see included:

• merb (with maybe some Rails for support... if required)
• HAppS
• seaside
• kepler, anyone?
• erlang
  

I think it would be great to show some of these frameworks side by side, performing similar tasks. Sure, the validity of the comparison would be limited by the scope of the project, but I think it would be nice to see functional apps from each, if we're going to keep hearing the same evangelism about Framework X or System Y every damn time I log on.

Cheers.

Google Gears

Google is at it again, this time maintaining its position at or ahead of the curve with Google Gears.

What is it? It's the latest in a great trend toward allowing for creating hybrid web apps that can run on- or off-line. Google Gears is by no means first to the party, however. Joyent was out the gates early with Slingshot, which we had the pleasure of getting a look at up at RailsConf. Adobe is also trying to get in the game (from an admittedly different angle) with its work on Apollo. Add in to this mix the browser-as-dev-platform path that Firefox 3 might be taking, and we can see that the world is moving very rapidly toward a synchronizable, online/offline world.

So why do we care about Google Gears? I'm sorry, that was a stupid question. We care because it's Google, and they have the intellectual resources to really solidly address this path, coupled with their penetration into just about every technological market. Also, they're following the grand tradition of their code projects, and opening a lot of code base for use by developers. The APIs are documented and available, and they're encouraging devs to play with the beta.

Gears provides the following basics, as quoted from their site:

	LocalServer Cache and serve application resources (HTML, JavaScript, images, etc.) locally
	Database Store data locally in a fully-searchable relational database
	WorkerPool Make your web applications more responsive by performing resource-intensive operations asynchronously

This should be enough for any web app developer to get off the ground and running, building relatively responsive RIAs... on the desktop.

Ok, enough drooling over docs. I'm going to go dig into it.

I'll probably post back later with impressions, but feel free to throw your comment in, too. I'd love to see how this is responding with different frameworks and on different platforms.