E-Scribe : a programmer’s blog

About Me

PBX I'm Paul Bissex. I build web applications using open source software, especially Django. Started my career doing graphic design for newspapers and magazines in the '90s. Then wrote tech commentary and reviews for Wired, Salon, Chicago Tribune, and others you never heard of. Then I built operations software at a photography school. Then I helped big media serve 40 million pages a day. Then I worked on a translation services API doing millions of dollars of business. Now I'm building the core platform of a global startup accelerator. Feel free to email me.


I co-wrote "Python Web Development with Django". It was the first book to cover the long-awaited Django 1.0. Published by Addison-Wesley and still in print!


Built using Django, served with gunicorn and nginx. The database is SQLite. Hosted on a FreeBSD VPS at Johncompanies.com. Comment-spam protection by Akismet.


Pile o'Tags

Stuff I Use

Bitbucket, Debian Linux, Django, Emacs, FreeBSD, Git, jQuery, LaunchBar, macOS, Markdown, Mercurial, Python, S3, SQLite, Sublime Text, xmonad

Spam Report

At least 237138 pieces of comment spam killed since 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:

  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.

Sunday, February 26th, 2006
+ +

0 comments pending approval
Comments are closed for this post. But I welcome questions/comments via email or Twitter.