In a recent article on DevX, Rick Strahl writes on “The Diminishing Importance of HTML”, and that “I am guessing that there will actually be a push back to desktop-driven, forms-based applications once .NET takes hold”.
Truth be told, I’ve been seeing this trend slowly building over the last year or so, evidenced by the release of more and more client-side technologies on both Java and .NET platforms. The problems with HTML, put bluntly, are myriad; in addition to the ones Stahl cites, I’ve run across the following:
- Portability: Despite the best attempts of the W3C to keep everybody on the straight-and-narrow, HTML still is one of the least-obeyed specifications in the Internet world. Both Microsoft and Netscape routinely do things that violate the spec, and XHTML has been all but forgotten. Now, arguably, with Microsoft’s ever-growing domination of the browser market (last statistic I heard said they owned something like 80% of the browsers out there), one could argue that you could just write to IE and call it a day, but then which version do you pick? How far back? There are literally dozens of different browser combinations a developer has to consider. OR, as a developer you choose to go with a least-common-denominator approach, and come up with a user interface that’s difficult for users to work with.
- Presentation: User-interface experts will rant on for days about how a successful user interface has to be painstakingly crafted to best support the user’s requirements: buttons must be placed just so, fonts must look exactly like this, and so on. Drop-down lists must be arranged so that they don’t cover information the user may wish to consult while picking from the list, for example. But HTML was intended from the beginning to allow for platform-specific rendering, which means UI experts can’t control the presentation of the interface as closely as they need to. Cascading Style Sheets was an attempt to solve this, but it can’t change how a browser renders form controls, and there are still some compatibility problems.
- Performance: Consider what a lot of these big companies are asking of HTML: data entry, data entry, and data entry. Because developers don’t want to use anything but plain-vanilla HTML, however, any validation of that data entry has to wait until the entire form has been submitted, at which point all of the errors will be flagged and sent back to the user for submission. In a rich-client application, however, we can catch those data validation errors up front, and prevent an unnecessary round-trip across the database, not only reducing traffic, but improving the system’s scalability as a result.
HTML was intended as a lightweight, easy way to present a user interface to a remote machine. As we ask more and more of it, however, it’s begun to break down and fray at the edges.
Why did we go to HTML-based interfaces in the first place? For reasons of Zero Deployment: before web apps, we built fat-client front-ends to client-server systems that were installed directly on the end-user’s desktop. When the database or business logic changed at all, we had to reinstall the application on the end-user’s desktop, and that’s a painful process if it’s not automated somehow. (Even when it is, such as using a network share, problems arise.) What we were seeking was a way to change the application without forcing the entire user community to come to a screeching halt waiting for the next revision. Server-based applications, such as those delivered via HTTP using HTML as their front-end, were the answer.
But the fact is, HTML is not the sole server-based presentation approach. Droplets and Sash (an IBM toolkit recently released from Alphaworks) and XUL (XML User-interface Language, which is how Netscape renders its UI in Navigator) offer much of the same advantages of Zero Deployment. Specific to Java, JNLP (Java Network Launch Protocol) offers a standardized way to fire a Swing GUI from within a Web browser, almost like an applet but with a more fine-grained security model (in theory–JNLP hasn’t exactly delivered on this promise quite yet), the ability to do automatic updates of the JDK required, and the ability to run the application locally if it’s not been updated since the last time it was run. Similarly, Chris Sells wrote an article in MSDN Magazine about how to achieve the same thing with .NET WinForms–in his case, a game he calls “Wahoo!”.
The fact of the matter is, users are getting tired of all the problems that creep up with HTML, and are demanding that we achieve “rich client” front-ends, even as we keep the benefits of distributed applications. It’s doable, and it’s up to us to recognize that and embrace it.