Why DHTML Will Win
Competition among user interface tools heats up
Reprinted from New Architect
By Steven Champeon
There's a lot of bold talk coming from a certain multimedia tools vendor (Macromedia, cough, cough) lately, about how its new Flash MX product is "the future of the Internet." Never mind that the company leaders seem to be confusing the Internet with the Web. What's interesting is how they demo this rich, multimedia future. The vendor's Web site makes much of an ETrade stock quote application-something that could have been thrown together in half an hour with Dynamic HTML (DHTML) without the need for proprietary technology, plugins, or a massive press campaign. How very 1997.
DHTML, you say? Tried that, hated it. It didn't work the way you had expected in [insert your favorite browser here], right? Well, it's time to take a second look. What you may think of as DHTML has advanced greatly since the early days of Web design. Back then, Microsoft and Netscape were in a pitched battle over which Document Object Model (DOM) would rule the Web: document.all or document.layers. But that has all changed. In the end, reason and the W3C have prevailed. Even Netscape, the company that created the <layer> element, has abandoned it in favor of the standard <div>. Developers no longer have to code for two different APIs.
So why the resistance to DHTML? Perhaps it's time for a new name. The past six years have brought enormous change, standardization, and stability (not to mention top-notch implementations) from the major browser vendors. And that isn't just because "Microsoft won the war." We all won the browser wars. Compromises were made on both sides, and the Web of tomorrow will bear as much resemblance to the antebellum days of Mosaic as your desktop resembles that of Bartleby the scrivener.
Because DHTML uses the components that your browser already supports, like HTML, Cascading Style Sheets (CSS), JavaScript, and the DOM, it requires no fancy authoring environments or server side applications. You don't need to learn another programming language or scripting variant, as some client GUI technologies require. You don't need to worry about the distinction between source files and binary files. And the sites that you produce can have a clean separation between document structure, presentation logic, and behavior-all of which let teams focus on their strengths, instead of forcing designers to program, or programmers to design.
What's more, the DOM and CSS were designed to work well with XML, a true enabling technology for which you should be preparing your company. (The latest version of HTML, XHTML, is already an XML document type. Thus, it's clear where things are headed.) Just try sharing data like that with a Flash file, or linking to a specific page in a Java applet.
DHTML solves business problems. It can be used to augment traditional, document-oriented sites as well as serve as the platform for a new breed of Web-based applications. When was the last time you needed scalable graphics and typography, animation, or sound to solve your business problems? (Unless you're in the online porn industry, or the Web multimedia authoring tools business, of course.)
You might object to this perspective on the grounds that we do, in fact, need client-side processing, personalization, reliable client/ server communication, and a way to save state without disrupting the page display. But DHTML lets you do all of that. And it doesn't require your customers to sit through needless delay while your plugins or virtual machines load.
Another of DHTML's advantages over its competitors is that you needn't worry about locking yourself into a proprietary platform. If you're building an application or updating your site, it's your decision whether to use a commercial, disruptive multimedia format owned by a single company and ruled by its financial ideology, or to adopt an open, standardized platform.
If you have a serious problem to solve, then the question is not "How should the Web evolve?" Rather, it's "How has the Web already evolved, and how can I take advantage of it now?" So, come back to Dynamic HTML for the very first time. You may be surprised at just how much DHTML resembles the Web we have right now, and vice versa.
Markup, Style, and Scripting
- Location - Location - Location: The Basics of Search Engine Optimization
- Cascading Style Sheets: Separating Content from Presentation (Italian), authors include Steven Champeon (buy it)
- Web Design on a Shoestring, by Carrie Bickner, edited by Steven Champeon (buy it)
- Progressive Enhancement and the Future of Web Design
- Inclusive Web Design for the Future, Presented March 11, 2003 as part of the South by SouthWest Interactive Festival.
Also available:- Japanese translation courtesty of Masami Tomosugi
- Spanish translation (currently offline) courtesy of Manuel Gonzalez Noriega of Simplelogica
- Web standards can save, and make you money
- The Secret Life of Markup
- Why DHTML Will Win
- Special Edition Using HTML and XHTML, by Molly Holzschlag, edited by Steven Champeon (buy it)
- Cascading Style Sheets: Separating Content from Presentation (English), authors include Steven Champeon (buy it)
- The Value of Standards for Web Design, Presented February 13, 2002 as Part of the North Carolina State University Ecommerce Learning Center seminar series
- JavaScript: Why You Don't Know More About It
- JavaScript: How Did We Get Here?
- My SXSW Swag: A State of the Web Address
- Javascript: Modifying Styles
- Working with Javascript: Introduction
- RTFM: A Guide to Online Research
- XHTML: Migrating Applications toward XML, by Simon St. Laurent, edited by Steven Champeon (buy it)
- XML: A Primer by Simon St. Laurent, edited by Steven Champeon (buy it)
- Building Dynamic HTML GUIs, by CTO Steven Champeon (buy it)
- XML: Extensible Markup Language, by Elliotte Rusty Harold, edited by Steven Champeon (buy it)
- The Veterans of a Thousand Browser Wars
- An Open Letter to Netscape
