Get Fired

I once swore I would never program in client-side JavaScript again. This was about the time that IE was first starting to take over the world, and Microsoft were promoting rubbish like JScript. Actually I swore a lot back then, but now we have a new age of JavaScript enlightenment, with Ajax, Web 2.0 and FireFox brightening the JavaScript world. Bless you, FireFox.

Of course, I never really stopped writing client-side JavaScript. It's unavoidable. Lately I'm working on a framework to query imported XML objects, in a xpath-like way. Which, it turns out is complicated enough to require some debugging effort. But how much does it suck to have to alert()nine-hundred times? I can tell you it sucks a lot. Haven't things improved any more than that in all these years?

Well, things have improved. A lot. I just discovered a little miracle called FireBug and the only swearing I've done since installing it is of the "Holy $!@ this is good!" variety. More evidence that the future of client-side JavaScript is looking very bright indeed.

Speak of "testing JavaScript" and most developers will conjure up images of editing an HTML file and then hitting reload on their web browser. That's probably not going to change, at least not as long as web browser support for JavaScript is so unpredictable. But if you have files of JavaScript you find yourself using more than once, you need unit tests.

Randal Schwartz said it was like "training wheels without the bike" -- so why would anyone want to turn Perl into PHP? Dag Ågren explains it as a "travesty", a "joke" and something to "make Baby Jesus cry." We know it as PerlHP, and it comes pretty close to putting training wheels on the carbon-alloy LeMond racing bike of Perl. But is that a good thing?