JavaScript and the thickening client

PROGRAMMING, JAVASCRIPT, WEB DEVELOPMENT

In recent weeks I’ve been listening to the back-catalog of Ajaxian podcasts while commuting. It’s been great food for thought for me, since I’m one of those people who retreated to the server side years ago to avoid the horror of incompatible, standards-oblivious browsers and crazed animated status bar messages. Things seem to have gotten a lot better, to say the least.

Here are some things that these podcasts have prompted me to think about:

  1. The client is getting a lot thicker. It is de rigeur for a Web 2.0 app to use prototype/script.aculo.us/dojo/mochikit in its user interface. Despite making great strides in modularity, these libraries can push page weights way up. Not everyone can switch to moo.fx. I’m wondering (in a lazyweb kind of way) whether you could write a Greasemonkey script that looked for references to these libraries and instead of loading them remotely, pulled in a local copy? Of course this would be fragile and dangerous, but Greasemonkey users live on the edge anyway. They could iron out the bugs and pave the way for a more sophisticated local caching system.

  2. The culture around Javascript has really evolved. Five years ago it seemed to be about copying and pasting snippets, or maybe using JimBob’s Javascript Library (which had functions for making crazed animated status bar messages). Now we have large-ish open source projects based around JavaScript. We have well-tested runtimes that work outside the web browser. We refer to JavaScript as a “prototype-based language” instead of “damned JavaScript.”

  3. JavaScript itself may become a sort of choke-point in the web application stack. If I’m building a web app I can choose Apache or Lighttpd, I can choose Ruby or Python or Java or PHP, I can choose Rails or Django or Seaside, I can choose Clearsilver or Smarty or Cheetah templates, I can even choose my (X)HTML dialect. But practically speaking I can’t choose anything other than JavaScript for client-side control. I wonder how long it will be before we have a more advanced client-side scripting API, and what it will look like. Perhaps some kind of virtual machine, with the client-side scripts sent as bytecodes instead of text.

So, those are my big ideas. It’s interesting to be thinking about the client side again. And I know, I know – ECMAScript.

Share: