Google ported Rails to JavaScript?

Apparently Google developer and blogger Steve Yegge has ported Rails to JavaScript.  I guess this this means we know what language Steve was referring to in his essay “The Next Big Language“.  This news also sheds some light on what Steve’s rather odd allegorical story “The Old Marshmallow Maze“.  It seems clear that the “floating platform” in the marshmallow maze story is his Javascript version of Rails.

I wonder if Google will release the source to this project?  I know I’d love to see it.  I like the idea of using the same language for both the client and server side.  And Javascript really isn’t a bad language.  Most people’s negative impression of Javascript stem  from the poor development environment available in the browser and the massive pain-in-the-ass that is the DOM.  Javascript is not the culprit, but it usually gets the blame.

But even if it is released publicly, will Javascript on Rails take off?  I don’t know.   There’s been at least one other attempt to create a Rails like framework in Javascript (TrimPath Junction) and  frankly, I’m not that impressed with the code sample listed on the TrimPath Junction web site.  Javascript just isn’t as concise and readable as Ruby.

FireBug

A couple days ago I posted about a FireFox extension that gives you a live JavaScript REPL running inside the currently loaded web page. Since then, I stumbled across Firebug, which IMHO may just be the greatest web development extension for Firefox since … err.. well since the Firefox Web Developer extension!. Firebug allow you to open a panel across the bottom of your Firefox window that gives you a ton of functionality including inspecting the HTML of any highlighted part of your currently loaded web page, inspecting registered Javascript event handlers, etc. It even includes a very impressive JavaScript debugger and profiler. Check out this video for an overview!

Maybe it’s time to learn Javascript?

My efforts to learn Scheme have stalled a bit lately. I’ve been quite busy both at home and at work. Unfortunately, I think that project is going to have to go on hold even longer. I do still plan to finish learning Scheme and/or Lisp, but I think I’m going to first spend some time getting better acquainted with Javascript.

Why? Good question. As I mentioned in my last post, I think we’re entering a new era for web application development. Web applications are going to be less about pages of html (with perhaps some snippets of Javascript to add a few dynamic behaviors). Instead, I think we’ll see more real applications, written in Javascript, that run in the browser. Some of the HTML and CSS will be static in the file, some will be loaded from the server (with XMLHTTPRequest or hidden IFrames), but a lot of it will be generated programatically.

I wouldn’t actually be surprised to see a web based app whose only server side component is some static files and a web service (REST or SOAP/RPC model). All of the user interface logic would be client side Javascript and DHTML. The Javascript client side application would call the web service to load/save/query any persistent data.

Sound far fetched? Check out this screen-cast from Jon Udell. In it, he demonstrates an amazing Javascript IDE/GUI builder from, of all people, TIBCO. It looks very impressive for being entirely client side Javascript. Of course, being that it’s a TIBCO product I’m sure it’ll cost an atrocious amount and probably have some kind of insanely restrictive license. 🙂

Tiddlywiki and the future of client server computing

GTD TiddlyWiki is a small HTML personal productivity app. It’s based on the workflows and lists from the popular book Getting Things Done by Paul Allen, so you’ll find the usual GTD lists like Next Actions, Projects, Agenda, Waiting, etc.

I’ve always thought the idea of using a Wiki to keep your GTD lists seemed kind of dumb, but after trying out GTD Tiddlywiki I have to say I’ve reconsidered. GTD Tiddlywiki does a nice job of combining the speed and simplicity of a classic Wiki, with some nice user interface fluff like an attractive side bar menu (generated by the contents of a special Wiki page of course), window animation, disappearing/reappearing rollover menu bars, etc.

But what really makes GTD TiddlyWiki so damn cool isn’t what it does, but how it does it. It’s completely client side (Look ma! no server!) and is completely contained in one HTML file. That’s right, no CGI, no executable. It’s completely done in client side JavaScript, CSS, and HTML. Now that’s cool!

GTD TiddlyWiki is actually a slightly customized version of the original TiddlyWiki TiddlyWiki. The changes are mostly cosmetic, but I think they succeed in changing the *feel* of the application from an odd personal web page/notebook into something that feels like a real application.

I’ve been using GTD TiddlyWiki for a few days now, and I think it’s going to become my GTD/PIM application of choice. I like that it’s a lot more freeform than Entourage, I like that my data is stored in a nonproprietary format (HTML DIV tags), and I like that it’s cross-platform.

But what really has me excited about TiddlyWiki is what I think it represents. TiddlyWiki is a glimmer at how far client side javascript and DHTML can go. Essentially, it *is* an application, but with no plugins or servers in site.

Almost everyone on the net has been blogging about how the future of web apps is DHTML and XMLHttpRequest, but I know I was still thinking in terms of feature enhanced web sites like Gmail.

What I’m now realizing is that the future of web apps may look a lot like the past of client server computing. The difference will be that rather than separate installs for each client application, the browser will be the “universal” virtual machine. Future web apps won’t be just feature enhanced web pages, but complete application that just happen to use HTML and CSS to draw their user interface and happen to use HTTP to communicate back to the server.

This is very much the future that the industry pundits were promising us during the early days of Java. Java applets never lived up to their promise, but I think a platform of Javascript, DHTML, and XMLHttpRequest will.