The html times

Elegantly Powered by Google

The Fattening of the Client by Sam Clearman October 1st, 2008 Delicious



No Relevant Downloads


The Fattening of the Client

(Or, “Why Every Ruby / PHP / Java developer Needs To Brush Up On Their Javascript Right Now”)

Rails developers who have moved to Rails 2 will have noticed that the scaffold-generated controller now include the following line in every action:

format.xml { render :xml => @model }

Most have probably discovered that it is extremely easy to add, for example:

format.json { render :json => @model }

These increasingly ubiquitous lines of code are the harbingers of a new era in web application development: an era in which Javascript is the only important language.

(To those of you out there protesting, “But Javascript is a terrible language! It can't possibly take over from my superior language”: you're wrong )

Basically, due to the browsers' exclusive use of Javascript for their programming environments, we are stuck with Javascript (discounting the possibility of, say, some lunatic writing a Javascript implementation of Python), and therefore energy expended on other languages is redundant and wasteful. Of course, this has been true for a while. But it's only now that, thanks to emerging technologies like Sproutcore and CouchDB, the Javascript dominance will be realized. As more and more of the logic of web applications moves to the client (and therefore to Javascript), the vestigial server side code, and the languages it is coded in, will look less and less important.

A brief history of crap

The current era of web programming began with the advent of Ajax techniques. Ajax, the use of the XMLHttpRequest call to build more dynamic interfaces, was a great leap forward for the quality of user experience that a web application could provide. The Rails framework's sudden explosion in popularity was, in part, due to the helpers that it provided for implementing Ajax interfaces: Using Rails helpers like link_to_remote and RJS templates, developers could get in on this Ajax thing without needing to write a single line of Javascript. Of course, with great power comes a whole lot of crap.

Dan Webb pointed out a flaw in the Rails approach to Javascript early on: The code they generated violated the principles of Unobstrusive Javascript, a development methodology that aims to keep the behavior (Javascript) layer of a web application cleanly separated from the semantic (xhtml) and presentation (css) layers. He aimed to solve this problem by releasing UJS4Rails, a plug-in to generate unobtrusive Javascript from within the Rails helpers. Eventually, however, he decided that while the Javascript extension to Prototype he had created (it became LowPro) was useful, the Rails plug-in did as much harm as good and it was simpler and cleaner to just write Javascript in Javascript.

The larger problem, though, isn't that the code Rails produces isn't UJS-compliant. The problem is that the entire philosophy of taking on Javascript functionality in a piecemeal fashion using Ruby code that generates Javascript code is completely insane. The fundamental flaw is that Rails treats a piece of Javascript behavior as conceptually equivalent to a piece of html code. This doesn't work.

The great leap sideways

I'm going out on a limb here, but it's my belief that the Rails approach to writing browser-based applications is doomed (any model that leads to something as crazy as Jabl has clearly gone off reservation). As in all things, the most simple and straightforward approach is the best: If you're writing a Javascript application, write a Javscript application. Of course, for most of the web's history, Javascript has been regarded as a quick and dirty way of making advertising pop up in the background. While Prototype, jQuery, and their ilk have made writing Javascript / DOM applications less than excruciatingly painful, they don't really provide much help beyond fixing the worst of the problems with the DOM API and giving you some handy visual effects to play with.

Sproutcore is a full-blown MVC framework for Javascript. It has gained sudden prominence thanks to basically being acquired by Apple and used internally for Apple's new suite of web applications. Although I have a number of problems with Sprout's implementation, it seems clear to me that it, and the imitators which will no doubt spring up to suit different programmers' styles, are the future of web development. Once you have a powerful toolkit for writing cleanly organized Javascript code that you are forced to use by the browsers' monolingualism, why not just put as much functionality in there as you can? Heck, if you are running a model layer in your Javascript application, why couldn't that model layer talk directly to the database?

CouchDB is a next-generation database being developed by Apache with a number of really interesting technical features, notably extreme scalability. However, what I'm concerned with today is one particularly interesting decision that the CouchDB developers made: They made the database communicate with plain HTTP and give its responses as JSON objects. Suddenly, the entire server side web application becomes unnecessary. The Javascript application on the client side can talk directly to the database and cut out the middle man.

This scenario isn't currently possible. For one thing, there is no security in CouchDB currently, so it has to be run behind a firewall. And it doesn't seem likely to me that the need for an application to handle this sort of thing will ever disappear: Would you want to implement the complex permissions involved in, say, Facebook, directly in the database? But a great deal of the code currently running on servers is responsible for handling stuff that would be much easier and more appropriate to do on the client side. Chief among these concerns is state, the bane of web applications (if people are willing to use smalltalk to avoid the problem, you know it's a problem) which is no longer an issue whatsoever in a client-centric development model. But in general, most of the code in any graphical application is always going to be in service of the GUI, and all of this code will be written in Javascript.

Rhino you are, but what am I?

So now that you have the majority of your application logic being written in Javascript, with only a thin layer left to write on the server in any language that you choose, why wouldn't you just choose Javascript? CouchDB does exactly that: Although the database itself written in Erlang, developers use Javascript to write the map/reduce functions that are the key to its power. Rhino on Rails is a port of the entire Rails framework to Javascript: a bit crazy, but it demonstrates what is possible. I'm not arguing in favor of language homogeneity. I think that different languages are best for different tasks, and even if they weren't, they're fun to have around anyway. But I do think that in the future, when web developers have a problem to solve, Javascript will be the first weapon we turn to.


Comments

Comments are now closed

Related Articles:

Editing In Place With Prototype

By Thomas Steinmetz Oct. 1st 2008

Resident programmer Thomas Steinmetz walks us through the cleanest, driest, and most direct method for editing in place with Prototype. Read more …


Under the Hood Of BandCamp

By Sam Clearman Oct. 1st 2008

Serial software developer Joe Holt talks to Sam Clearman about his newest project, BandCamp: the website for bands and their music that finds a new revenue model for the record industry.
Read more …



Information Wants To Be Free

Elegantly Powered by Google