Information Age: News, analysis & insight for IT & business leaders

When the application service provider (ASP) idea first emerged in 1999, it quickly became apparent that the technology was not there to support it.

Basic HTML, the bedrock of the web browser, could not provide the richness and interactivity required, while using thin client software from vendors such as Citrix, for example, simply added to the cost and did little to reduce the management overhead.

Dynamic HTML, a catch-all term for a number of technologies that could bring greater interactivity to the web browser, promised an answer, but fell victim to the browser wars between Microsoft and Netscape. Not only did each vendor interpret the standard in its own way, there was often not even consistency between different versions of the same browser.

But when the browser wars died down, developers were able to catch up. So far, software suppliers offering browser-based applications, including Salesforce.com, have benefited. So too have in-house developers within many organisations: They have been able to make browser-based applications simpler to use and web-enable legacy applications by building a DHTML front-end.

Microsoft's Outlook Web Access (OWA) function provides a good example of what can be done with DHTML. OWA reproduces the conventional Outlook email client with startling accuracy and functionality in a standard web browser, even a non-Microsoft browser.

Finally, it seems that DHTML's time has come. "DHTML provides a level of interctivity to the web browser that was previously impossible," says Ron Zambonini, CEO of Cognos, the business intelligence software that has re-written its user interfaces in the browser language.

But it could find that its window of opportunity is closing. While DHTML has matured to a level in which serious applications can finally be delivered via the browser, it still has a number of shortcomings.

For example, interactivity is still relatively limited, says Russell Jones, executive editor of developer magazine DevX. "You can't even draw lines in a browser with DHTML," he says.

There are other limitations. Browser-based applications cannot take advantage of improvements in graphical user interface (GUI) design, for one. "Some things that are common in Windows applications simply aren't available in native form in DHTML without installing plug-ins," says Jones.

Some third-party developers have partly mitigated this by providing frameworks for writing DHTML-based applications, which make it easier to build some Windows-like capabilities into browser-based applications.

Even so, DHTML browser-based applications still will not offer the richness of an old-fashioned two-tier client/server application, running on a local PC. As a result, some observers suggest that the scope of browser-delivered applications will be limited for a long time to come.

But they are not predicting a return to old style client/server. Instead, applications will increasingly be delivered from the server, using the HTTP transport mechanism that is synonymous with the Internet, but which will run directly on the PC's operating system instead.

Similar to a Java applet running outside the browser on a Java virtual machine (JVM), to all intents and purposes it will look, feel and operate just like a natively running PC application.

And the idea is not so far-fetched. It has been possible in Java for some time and, indeed, it is the direction in which Microsoft is moving towards with its .Net framework. In .Net, byte code can be downloaded and executed on the client 'on the fly'.

Furthermore, a .Net application running on a Windows client offers the possibility that it could exploit Windows functions - although this could lead to proprietary vendors maintaining control of client software. DHTML can also still contribute much to many applications, particularly given the maturity it now offers and the wide cross-platform compatibility it now offers.

"Given the relative stability of support for [browsers such as] Mozilla, Safari, Konqueror and even Internet Explorer, it still makes an attractive platform for client-side interactivity," says Steven Champeon, CTO of development firm Hesketh. He adds: "With the XML capabilities of recent browsers (at least on the JavaScript side of things) it's a great set of tools."

Yet as corporate PCs are upgraded from 300MHz-based machines to 3GHz-based machines and high bandwidth becomes ever more reliable, a return to applications that look and feel just like old-style two-tier client/server programs seems increasingly inevitable.

Whether they are Java-based, .Net-based or even built around Macromedia Flash remains to be seen.