About Me

PBX I'm Paul Bissex, and e-scribe.com is my consulting business. I build web applications using open source software, especially Django. In the '90s I did graphic design for newspapers and magazines. Then I wrote technology commentary and reviews for Wired, Salon.com, Chicago Tribune, and lots of little places you've never heard of. Feel free to email me.

Book

I'm co-author of "Python Web Development with Django", an excellent guide to my favorite web framework. Published by Addison-Wesley, it is available from Amazon and your favorite technical bookstore as well.

Colophon

Built using Django, served by Apache and mod_wsgi. The database is SQLite. The operating system is FreeBSD, on a VPS hosted at Johncompanies.com. Comment-spam protection by Akismet. Vintage topo imagery from the Maptech archive. The markup engine is Markdown.

Pile o'Tags

Stuff I Use

Akismet, del.icio.us, Django, dpaste.com, Emacs, FreeBSD, Freenode, jQuery, LaunchBar, MacPorts, Markdown, Mercurial, OS X, Postfix, Python, SQLite, Subversion, TextMate, Trac, Ubuntu Linux, wmii

Spam Report

At least 70644 pieces of comment spam killed since January 2008, mostly via Akismet.

JavaScript and the thickening client

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:

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.
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."
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.

Sunday, February 26th, 2006
javascript + programming + web development