Rethinking Javascript
I’ve had to completely rethink my attitude toward Javascript in recent months. My former attitude was, roughly speaking, as follows:
- It's a weak language, designed as a macro facility to let people animate pages back when animation seemed really important.
- It’s badly standardized, so almost anything written in Javascript will be fragile.
- Lots of people have Javascript disabled, so you can’t rely on it.
- Whatever you do, you’re still running in a box hanging off the side of a process. You can’t build products, really, because they're too easy to copy and too easy to appropriate. So what you can do, at best, is sell support and documentation.
I think this used to be more or less true, but it’s not true any more. My new understanding:
- It’s an adequate language with an interesting mix of strengths and deficits. It’s got prototype inheritance; Tinderbox users know I'm a big prototype inheritance fan.
- Web 2.0, whatever the term meant, drove convergence toward an effective de facto standard. MSIE isn’t the problem it once was.
- A ton of work is underway on making Javascript interpreters run fast. Really fast.
- Javascript provides a really good way to fix the browser, or even the markup. In the old days, if a browser had a bug you either deleted the feature or wrote browser-specific markup or variant pages. Now, you let Javascript work behind the scenes to silently add whatever ugly additions you need.
For the stretchtext project I'm working on, I’ve got lots of ugly link markup:
<a href="javascript:void(0);" onclick="expander('.3');return false;">Naturally, I hid all the crud behind Tinderbox macros: ^do(expander,....). But it's still unsightly. Instead, simple javascript magic lets us write something clean
<a href="help.html" class="expander">and transform it behind the scenes into whatever cruft we need. This gives us cleaner markup, and another layer of indirection.