few years ago, Microsoft released Internet Explorer 4, which changed the course of Web client-side development. Not only was it ubiquitous, delivered with every version of Windows, but it also introduced a technology called Dynamic HTML (DHTML), which combined Cascading Stylesheet (CSS) technology and scripting to let developers circumvent the rigid layout and limited interactivity supported by HTML. DHTML gives developers programmatic access to the Document Object Model (DOM) for HTML pages. By controlling the DOM with script, you can access any object in the page, modify its contents, its position, its CSS properties, and even add custom properties (expandos) of your own. DHTML opened up wide vistas for Web developers, and seemed poised to dominate interactive client-side development. But the furiously churning browser market of the late 1990’s, users’ resistance to upgrading, and the incompatible DOM and CSS implementations between browsers caused the wave to collapse.
Today, years after DHTML was first introduced, things are a little better, but not much. Companies still feel (wrongly, in my opinion, and that of many other developers) that they have to support older and less capable browsers. But because of their limited CSS and XML support and proprietary DOM models, supporting these older browsers forces developers to write multiple versions of every page, so most decide that it’s too costly to bother. So the majority of pages on the World Wide Web are still plain vanilla HTML, with no interactivity beyond links and simple forms.
DHTML Alternatives
Fortunately, DHTML’s failure in becoming a generic client-side programming solution hasn’t stopped all development of client-side interactivity. Macromedia, capitalizing on the browser manufacturers’ inability to standardize DHTML, has nearly single-handedly captured the market with its Flash technology. By using installed client-side code rather than relying on script alone, Flash pages circumvent browser incompatibilities. Flash, by most reports, is ubiquitous; according to Macromedia, over 98 percent of all browsers support Flash. With its proprietary interface, and TV-like qualities, Flash currently rules the roost for building graphical interfaces that run on almost all clients. DevX’s Sightings feature is a testament?the vast majority of recognized Sightings over the past year are Flash-driven. And Flash capabilities are still growing. You can build Flash clients that act as front-end interfaces and consume Web Services to access centralized data and logic (see Drive Your Flash Front-ends with SOAP). But despite its growing capabilities and huge installed base, Flash doesn’t completely own the client-side development market.
Another contender pushing DHTML out of the picture is Java. Although popular press wisdom says Java applets are dead and buried, that’s simply not true. While Java has all but disappeared from most general Internet pages, applets are alive and well in the gaming world. Visit the Yahoo or AOL games pages at almost any time of the day or night, and you’ll find thousands or hundreds of thousands of people playing games?and the games are powered by … Java applets. Applets, supported by the rapidly maturing Java language, seem to have a lock on this segment of the browser interface market. Flash scripting and DHTML are not powerful enough, not fast enough, and too difficult to maintain for games that require rapid, near-real-time calculations, such as pool. The alternative?Microsoft’s ActiveX technology?although widely used on intranets, failed on the larger Web because it has full access to the local machine, giving downloaded code too much potential for abuse. Downloading and installing an ActiveX-based application via the Web is like diving blindfolded into a swimming pool?without knowing whether the pool contained water.
This time however, Microsoft may have gotten it right. Just as it did with the introduction of Internet Explorer and DHTML, Microsoft is changing the face of Web development with its .NET framework. .NET looks like it has the legs to muscle into Flash and applet territory. Like Flash, you can manipulate graphics and audio using the built-in GDI+ classes or via COM interop with existing technologies such as DirectDraw. Like Java applets, .NET client applications download and install automatically. Like Java applets, .NET applications are fast enough to build interactive games. Like Java applets, .NET applications run under fine-grained security restrictions, making them relatively safe to download and install. Like Java applets, .NET applications have well-integrated network capabilities; in fact, there’s little difference between programming local objects and programming remote objects.
But .NET applications aren’t Java applets. Unlike Flash and Java, .NET technology doesn’t require a browser. Unlike Java applets, .NET applications have the full power of Windows, including the familiar native interface controls, access to COM technologies such as DirectDraw. Given sufficient permissions, they can interact with and integrate existing Windows applications, such as Microsoft Word, Internet Explorer, and all the myriad COM components. Unlike Java applets, .NET applications run as native code?even better, that code is compiled Just-In-Time (JIT) so it can take full advantage of the local processor. And they’re small. The .NET runtime is chock-full of classes that support most of Windows’ capabilities, so applications compiled with .NET need to add only the logic needed for that specific program. That means they download as quickly or even more quickly than do Java applets and DHTML-based applications.
So where does this leave DHTML? My guess is?out in the cold. If you can’t trust it to run on every client?even on every Windows client; if you can’t use it to create graphic-intensive multimedia applications; if you can’t use it to build interactive games; if every distributed application niche has a better alternative, then DHTML is an orphaned technology.
If you agree that DHTML is on its last legs for application development, then you might also agree that browsers are likely to follow suit. I don’t mean for general surfing?there’s too much flat-HTML information available for browsers to disappear anytime soon?but for distributed application development. Until now, developers have often built two versions of applications?a desktop version, for clients hard-wired to the network, and a browser-based distributed version, for remote and mobile workers. But as soon as you no longer need DHTML or browsers to build distributed applications, browsers become irrelevant. You can easily build a .NET application that acts like a browser, in that it gets its information from a central location via HTTP, that downloads, installs, and upgrades dynamically, like Java applets?but that has the interface advantages and power of a standalone, custom-built Windows application. Not only that, but you can build a single version of that application that adapts to either a remote or local environment. That’s tough to beat.
Still, .NET has a steep hill to climb before it will begin to make a huge impact on the existing game and multimedia market. Unlike Flash and Java, .NET is not cross-platform?yet (there are efforts underway to translate the core portions of the .NET platform to other platforms). For now, if you want to develop .NET applications, you’re limited to Windows clients?but as those make up over 90 percent of all clients, it’s not that much of a limitation. .NET doesn’t have the built-in graphics and timeline manipulation tools that Flash already has; in addition, the first version of the .NET runtime doesn’t integrate some of the functionality that developers need to build graphic-intensive and multimedia applications. For the game market, there’s little need to build a .NET version of popular games unless Microsoft somehow ups the ante by improving play significantly. No, where .NET will shine immediately is in distributed business applications. Fortunately, that’s where the money is.
In addition, there’s that pesky runtime. Although you’ll be able to download the runtime soon, it’s not a trivial download for most remote dialup users. Microsoft will probably deliver the runtime with future versions of Windows and with popular applications such as Internet Explorer and Office (sheer speculation on my part?I have no inside knowledge of Microsoft’s plans?but that only makes sense). Even with full support from the developer community, which Microsoft most certainly does not have, it would take several years for developers to be reasonably certain that the .NET runtime is installed on every target system. Nonetheless, I expect .NET to gain quick entry into the business market, which, again, is where the money is.
Finally, there are the developers themselves. Currently, .NET is a programming system without programmers. The product isn’t released yet, and despite a huge beta program with hundreds of thousands of participants (if you count downloads as participants) it remains to be seen whether Microsoft can migrate its existing classic VB developer base to .NET successfully. For the past year, there has been a sometimes bloody ongoing debate on DevX’s VB.NET discussion group about this very point.
The bottom line is: DHTML is dead for serious application development; browsers, as application delivery platforms, are past their peak; and the future of distributed, interactive applications?at least on Windows?belongs to .NET. If you’re developing these types of applications and you’re not learning .NET, you may want to rethink your career plans.
