JAN 23
My various web sites, such as prestonhunt.com, Trainster, and Nagbot, have gone through many distinct phases with respect to Javascript:

Phase 1, the original sites: Static content only.

Phase 2, not long after phase 1: Script-generated (usually Perl) static content on my home machine, pushed by cron job to my web host. Still no Javascript.

Phase 3, about five years ago: As little Javascript as possible, but heavy reliance on server-side scripting such as CGI, Perl, and PHP. I used to feel that Javascript support in browsers was too inconsistent to be used effectively. Then Google Mail and Google Maps came along and showed everybody how things should be done.

Phase 4, about two years ago: Not wanting to become locked in to a particular toolset, I eschewed Javascript frameworks like Prototype. I coded all Javascript myself. This was often a laborious task given the lack of good debugging tools and also the infuriating inconsistencies between browsers (of which IE6 is far and away the worst offender).

Phase 5, about one year ago: Finally bit the bullet and adopted the Prototype framework. Life got a lot easier, but Prototype itself doesn't do all of the Ajaxy things that I like to do (like auto-complete-as-you-type, light boxes, fade effects, and so on). So I started layering different libraries, including Scriptaculous and MooTools.

Phase 6, about two months ago: I've found religion, and its name is JQuery. JQuery's elegance is so beautiful that it almost makes me want to cry. The documentation is outstanding. And it encourages community support through plugins, which quickly become indispensable -- stuff like auto completion, rounded corners, table sorters, tooltips, calendars, etc. And because the plugins are all based on the common JQuery foundation, they usually play nicely with each other. I'll be posting soon about how JQuery has made life much easier for me. In the meantime, I'm busily migrating all of my sites to it.

Related links: Why JQuery's Philosophy is Better, JQuery - Javascript that doesn't suck!

tags: webdesign programming
permalink | comments | technorati
JAN 12
I've finally gotten with the times and ditched CVS in favor of Mercurial for many of my active projects. I have to say, it's pretty nice.

One feature I really like is the ability to make local commits to a repository and then ship out all of the changes at once to other users (or to a central repository) in a single changeset.

Another cool feature is being able to rollback mistakes. And having an automatic repository wide id with each commit eliminates the need to tag all the time like in CVS.

This presentation at Google from a Mercurial developer is very good. Also, this talk from Linus on his revision control software, git, is good at explaining why you should upgrade if you are still using CVS or SVN. I wish I had switched a lot sooner.

Here's another good piece on git vs. Mercurial vs. SVN.

tags: programming source-control
permalink | comments | technorati
Javascript is a very powerful language. I continue to be amazed by what can be accomplished using its prototypes and associative arrays. But its loose typing and reliance on external interpreters means that any non-trivial program will eventually require hours of testing and debugging on each platform that you want it to run on (Firefox, Internet Explorer, Opera, Safari, ...).

In an attempt to minimize this debugging time, I set out a while back to find a lint program that would check for bad coding practices. I found JSLint, but quickly learned that it is far too picky on what it reports as problems. For example, it will report the instantiation of a class if it hasn't been assigned to a variable:

 new Ajax.Updater( ... );
instead of

 var j = new Ajax.updater( ... );

This is perfectly legal Javascript and often a good idea. For example, when using Prototype, the Ajax.Updater class doesn't return anything useful. There were numerous other bogus warnings from JSLint.

I also wanted to integrate Javascript checking into my local build environment. Since JSLint appears to be online only, this was not convenient.

Recently I found JavaScript Lint, a command-line tool that does exactly what I need. It comes with an extensive configuration file that lets you control exactly which warnings you want to suppress. So, for example, I don't like warnings complaining about missing semicolons at the end of lines as this is perfectly legal in Javascript! But I do want warnings about variables that are used without being declared first.

Check it out if you program Javascript!

tags: javascript programming
permalink | comments | technorati