Once upon a time, I had to conform to a coding style that demands elaborate headers for every function, no matter how small. Worse, the header contained the name and parameter list from the function, introducing an annoying touch of duplication. I'm too impatient to type something twice, and too lazy to get the formatting juuust right, so I decided to write a tool to do it for me. Since I suffer from hubris, I assumed everyone else would want my tool too.

The problem was fundamentally trivial: take a function declaration, pull out the name and formatting list, and output the header to be copy-and-pasted into the IDE. So, I had to choose an environment/release mechanism. These were the constraints:

• the environment needed regular expressions
• it should look nice and include on-screen instructions
• It had to have some option buttons to choose between a couple of formats
• it should be super easy to deploy
• it should be able to be called from a hotkey

"Super easy to deploy" is critical. I once saw a tool for laptops that would cache a bunch of important information so you could still be productive with a slow or nonexistent connection. It couldn't have been more than a page of code, but it required the .NET runtime, which wasn't installed on our laptops by default. I found myself in a hotel room on dial-up, with this tool telling me it had to download thirty megabytes if I wanted to get anything done on the flight. Joel Spolsky had a similar experience with another trivial .NET program.

Easy to deploy usually means a web app. That would work: I could publish it on the intranet and use JavaScript to do the regular expression parsing. And it's easy enough to include instructions and options button in an HTML document. However, that meant that it would have to live on the network. I (and the other programmers) travel sometimes, so we often work on laptops, not connected to the intranet, or over a slow connection. So, I decided a local file would be better.

Do you see the problem for HTML?

Internet explorer locks down JavaScript for any HTML document run from a local file (because it has some access to the local drive.) and it takes two clicks to enable it. Two clicks is forever!

That's when Farhan Ahmad put me onto HTML Applications. HTAs are just HTML that runs with increased permissions from local files. Normally, you'd use VBScript to access whatever you needed, but I'd never used VBScript, and didn't need to access anything, so I used JavaScript. It worked pretty well, and since then I've used the same strategy to come up with several similar small utilities. HTAs are an evolutionary dead-end; there's no reason to invest time in learning about them. On the other hand, it simply doesn't take very long, and it's an interesting precursor to WPF. Starting from Farhan's VBScript example, Here's my JavaScript example if you're interested:

HTAs are not popular and will soon be forgotten completely, replaced by more sophisticated solutions. But at one particular moment in time they solved one particular deployment problem quite neatly.