In this regard, VB is very different from C++ and Java IDEs like Visual Studio and Eclipse, which make it easier for a skilled developer to create applications but do little to support a role for non-programmers.

VB's other key innovation was its VBX (Visual Basic eXtension) architectures. Using VBXs, a C developer could create a packaged extension to Visual Basic. This mechanism provided a way for senior developers to create components that could be re-used by VB developers. This capability improved the productivity of development teams by allowing them to specialize; scarce senior developers could package complex functionality into simple components that could be leveraged repeatedly by VB developers, whose background and focus centered more on the needs of the business user and less on the science of coding.

Eventually VB evolved its own component marketplace. Many small software startups came into existence, all creating specialized VB components that reflected their unique industry experience. These components ranged from specialized charts and graphs, to very specialized dials that looked like those on manufacturing machines, to mapping/GIS components that allowed the end user to display business data on a map.

The Web Factor
Naturally, we can't talk about the history of enterprise computing in the 1990s - or the state of enterprise desktops today - without factoring in the Web.

The first usage of the name "WorldWideWeb" occurred at CERN in Switzerland with a program created by Tim Berners-Lee on a NeXT computer in October of 1990. Four years later Mosaic Communications Corp was formed, later becoming Netscape, to capitalize on this new technology.

The Web browser provided a universal client that could present content (HTML) deployed on a central server. The Web quickly moved from being just a means of presenting content to a way to deploy applications because it eliminated one of the biggest problems with client/server applications - that of maintaining the installed client. A centralized deployment model is a big gain for enterprises as it allows them to deploy new versions of applications quickly, without the time and expense of installing new client software on each and every user desktop.

The Web gave enterprises another win besides centralized deployment, in the form of HTML's declarative GUI definition language. HTML further lowered the development skills barrier relative to even RAD environments, so that now "anyone" could create a simple Web page. This split-up of UI and application logic also enhanced application maintainability even as it constrained how client-side applications could interact with the server via simplistic HTTP posts.

But perhaps the biggest problem with the Web was that users lost the productivity advantages of those rich, interactive GUIs that could be created with client/server applications like Visual Basic. Productivity also suffered from the unreliable nature of the cheap, commodity public network called the Internet.

In the end, enterprises chose to trade-off the gain of universal access for the loss of capabilities for user-facing applications: less rich interactivity, reduced application reliability, and less robust communication between client and server.

Seeking the Best of Both Worlds
As Web browsers became part of the basic configuration for all desktop systems, they came to provide a standard platform for accessing content and applications. These early Web applications would be centrally deployed onto a Web server with extensions (CGI, JSP, ASP, etc.) that allowed an application to execute. Initially these applications accessed databases to allow simple CRUD (create, read, update and delete); over time, they grew in sophistication.

One popular approach to creating more sophisticated HTML applications has centered on the use of JavaScript. The core idea of this do-it-yourself method is to use the browser's inherent capabilities to provide the widest range of support for diverse client types; hence, it is well suited for consumer-facing applications like Google's G-mail. In general, however, HTML/JavaScript applications require users to download (potentially large) JavaScript libraries to compensate for the differing capabilities of various browsers. The resulting applications are as rich as the underlying browser will allow.

Java originally emerged as a new language that allowed the developer to create portable applications that would run on many different operating systems. It was initially perceived as a new way to create desktop applications and later (mainly in the form of the Java applet) Web applications. But given a number of issues with its ever-changing graphics APIs, Java's greatest value has thus far been realized on the middle-tier with the eventual creation of what is now called Java Enterprise Edition (Java EE).

Java EE did a better job than straight Java at segmenting presentation and business logic, and therefore gained a greater share of the middle-tier market. JavaServer Faces (JSF) represents Java's attempt at standardizing the many server-side presentation frameworks that came into existence to make creating and maintaining Web applications easier. Since it is primarily designed for server-side event handling, JSF does not address many of the limitations of Web applications relative to creating an interactive, productive presentation tier; however, it does make it easier to maintain whatever code exists.

There have also been various efforts to re-create the productivity enhancements available with VB-like application components, most notably ASP (ActiveX Server Pages). ASPs used a similar concept to ActiveX components in Visual Basic to encapsulate and re-use application logic. Since these components were relegated to the server only, they ended up just encapsulating middle-tier logic - typically generating images - which did not help with overcoming many of the maintainability issues with JavaScript.

But due largely to the fundamental limitations of the Web as an application platform, the quest for Internet-based, enterprise-class applications has proven elusive all along, and remains so today. During the dot-com days, many attempts were made to create HTML-based applications, but by-and-large these efforts failed if the application required complex data navigation or access to real-time data. The browser wars also hindered interoperability, making it difficult and expensive to test applications and complicating deployment and maintenance scenarios.

The Future Is Now
Today's enterprises have lived through several generations of desktop application technology: mainframe and UNIX-based green screens, PCs running client/server applications, and now the Web. At every point along the timeline, their focus has been to optimally balance the cost of desktop infrastructure against users' productivity requirements. No one fails to see the cost advantages of the Web's universal reach and centralized, no-install deployment model, but enterprises can't yet afford to give up the rich features and high reliability of their client/server architectures.

Enter what Gartner calls "the next evolution of the Web" - Rich Internet Applications. RIAs seek to deliver the best of traditional client/server applications with the global reach of browser-based access. They promise enterprise-class performance and productivity combined with reduced deployment and maintenance costs.