In other words, those five years of "downtime," was a time of real research and development, not done in hopes of getting that next crucial patent (or the million-dollar payoff) but rather done because the work represented real needs that needed to be rectified and it was to everyone's benefit to do so. Standards matured, projects started and worked and bloomed and died, and out of the remnants came new projects and the further tinkering with standards.

One of those revenant projects was the ghost of Netscape. I'm going to speak what's heresy here in San Jose, but Netscape failed because it wasn't good enough. You give away a perfectly good software product for free against a competitor who has billions in the bank, and while you'll find people cheering you on, they, and you, are idiots. You will fail. Netscape failed.

It failed largely because the only way it could compete was to change the rules of the game, for the project to divorce itself from the requirements of being a business. It became a ghost in the machine, one largely sustained by the efforts of Brendan Eich, who is one of the most brilliant and insightful people I have ever met. Brendan and others in the nascent Mozilla.org movement decided to create a browser using an HTML-like language called XUL that described the critical components necessary for an application to work, set up a fairly large set of core services written in C++ then proceeded to use JavaScript, another Eich invention, to tie the pieces together.

Ahead, Warp Factor 9 Powering the Web with JavaScript
Let me tell you a little bit about JavaScript. It's a simple language. Now, I know how to program in Java, and C++ and C# and Smalltalk and a few others that I've picked up over the years, but I've always liked the simple languages best. JavaScript has only a rudimentary definition of type, though it'll get more in upcoming releases. PHP is simple, and it's rapidly becoming the primary Lingua Latina of the server world, replacing Perl, which was also simple, but a little too indeterministic. John Thompson created Lingo for Macromedia Director several years ago, and much of the spirit of that language (along with JavaScript) still lies at the heart of ActionScript. JavaScript is the most ubiquitous procedural language in the world. There are more lines of JavaScript code in existence right now, I suspect, than there are lines of code in Microsoft Vista. It's a language that can be picked up by a bright eight-year-old, and yet now, as a programmer you can command a six-figure salary if you know how to write it well. It's important in great part because of its role as the glue that holds Web pages together, that powers Web applications, and makes it possible for you to boldly go where no one has gone before.

There's a lesson in that, a lesson that emerged with HTML (and that occasionally needs to be relearned on the XML side ‹ and even on the AJAX side). Simple is good. Indeed, perhaps more than that, simple is so friggin' essential that your development efforts will most likely fail spectacularly if you don't embrace that fundamental notion.

JavaScript provides a development environment that's on nearly every browser and increasingly in many other embedded applications (you can program OpenOffice in JavaScript, for instance). In other words, it's out there for anyone to use, and increasingly managing that JavaScript should be a part of your larger developmental efforts, because in the long run lowly JavaScript will trump Java, C++, C#, and just about everything else because of that ubiquity.

JavaScript has also been evolving pretty dramatically in the last couple of years, though this evolution may not be as evident if you've been working in the Internet Explorer realm. Getters and setters have become pretty much standard fare, array and object manipulation has become considerably more sophisticated and powerful, prototype functional programming is taking advantage of advanced features of languages such as Haskell and Miranda.

However, perhaps as significant has been a wholesale rewriting of the programming methodologies surrounding JavaScript to the extent that most dedicated JavaScript developers today write code that bears surprisingly little resemblance to that of even five years ago. For starters, object-oriented programming has become far more pervasive, even if the "object-ness" tends to bear only a passing resemblance to the class/property/method structures of Java or other similar languages. Code frameworks, such as the Ruby prototype.js object, scriptaculous, the Google and Yahoo AJAX frameworks, Atlas, and so forth, are emerging to handle the more common use cases, such as drag-and-drop operations, as well as spurring new interest in animated dynamic effects. XML manipulation (as will be discussed) is becoming easier, and a second graphical framework, the Canvas object, is opening up additional two-dimensional graphical capabilities.

There's even an emerging "live" object transport protocol, called JSON, that's becoming useful in low-level messaging systems. JSON uses the Java Script Object model N otation (hence the acronym) to represent JavaScript objects and to transport them across pipes (using the XMLHttpRequest object, discussed shortly). While JSON is a lightweight alternative to XML for certain tasks, and while it's not going to replace XML any time soon, JSON does work especially well in setting up object bindings, though it also represents a potential security hole that needs to be watched very carefully, as will also be discussed.

Beam Me Up, Scotty Messaging and the XMLHttpRequest Object
While JavaScript is the engine that drives much of the AJAX movement, JavaScript by itself isn't enough. Two factors have changed JavaScript from something that was almost an afterthought in most business circles to one that has been gaining a lot of traction ­ XML and the Asynchronous HTTP Messaging object, bearing the ungainly name of XMLHttpRequest object but best thought of as the Message Pump. The Message Pump can be thought of as a radio transmitter/receiver ­ it can retrieve content from an external source ­ a file, a Web server, or in some cases a database ­ and it can also send messages to external sources. It was originally a part of Microsoft's Internet Explorer ­ and for many years it was one of the better kept secrets in that environment, but the Mozilla folks were smart enough to recognize a good idea when they saw it (and in all honesty, the prototypes for the object were there in Netscape as well, but by then too many other fires were blazing for it to make much difference).

That message pump means that you can send information from the client to the server and back from within a Web page. Of course, you can do that anyway, but the important distinction is that with the Message Pump you're not necessarily forced into refreshing the entire page every time you need to change some aspect of it. In programming circles, this means that state management no longer has to be done exclusively within the server, but can in fact be significantly offloaded to the client.

Now, to take this back to the Star Trek metaphor again (hah, you thought I'd forgotten, hadn't you!) imagine the Enterprise without transporters (or look at the final series...or maybe not). You want to get valuable medical equipment to the colonists at Rigel 7, you have to launch a shuttlecraft filled to the brim with equipment and fuel, have it descend into a hot steamy jungle with only the vaguest hope of finding a convenient airstrip to land on, have to provide armed guards for the shuttle while you unload the likely heavy equipment then take off from an unfamiliar planet in hopes of a rendezvous with the mother ship two or three days later. This was Web programming circa 1998.

With the Message Pump and some intelligent JavaScript code you suddenly turn on those transporters (though you also keep the shuttles just in case Scotty isn't around to press the right levers). You send down an initial support staff via transporters who check the security, make the necessary arrangements, and find out what things are specifically needed. They can then call down equipment that can be positioned to within a few dozen yards of where it needs to end up, bring in additional personel to instruct and train the locals in the use of the equipment, and while there can beam up the few serious medical cases that need to be transported to a more complete medical center. Finally, everyone beams back up to the Enterprise and spend some well-deserved time on the Holodeck.