DHTML and Java Further Balkanize the Web
By Lincoln D. Stein
I am currently working with a biotech firm that is creating a large, Web-based application that combines databases, specialized data displays, and links to third-party software. Typical of this stage in the development of the Web, the application is written using a combination of C code, Perl, SQL, and a few Java applets. Although the application runs just fine, we're always bumping up against the limitations of the Web browser's user interface. On the Web, everything looks and acts like a hypertext document.
We'd like more from the Web. Our application needs to look and feel more like a desktop program, complete with icons, drag-and-drop folders, and toolbars. But we're in a quandry. If we stick with vanilla HTML, we're guaranteed that our application will run on all our customers' computers, a heterogeneous combination of UNIX boxes, Windows machines, and Macintoshes. If we go with either of the new technologies, DHTML, or even client-side Java, we throw away cross-platform compatibility.
If you thought that the tag wars of 1996 were bad, 1997 saw the introduction of not one, but three different definitions of dynamic HTML: Microsoft's, Netscape's, and the more modest specifications for absolute positioning and style sheets proposed by the World Wide Web Consortium (W3C). Although there are many likenesses between the two browser vendors' implementations, the differences far outweigh the similarities. Steve Holzner, in his lucid webdeveloper.c