After Microsoft upped the ante in the browser market in 1996 by integrating Internet Explorer 3.0 into Windows, Netscape began the new year with a renewed focus on the open web. Co-founder and CTO Marc Andreessen, along with the Netscape product team, introduced a new strategy called “crossware”:
This was a not-so-subtle dig at the known security flaws of Microsoft’s ActiveX platform, which could access local Windows resources (sometimes to the user’s detriment).
The browser wars were heating up.
Components: JavaBeans vs. ActiveX
Netscape’s DevCon 3, its third developer conference, was held from 11-13 June, 1997, in San Jose, California.
One of the key announcements was that Netscape would be using Sun’s JavaBeans technology as the component architecture for its web development platform (which went by the name of Netscape ONE). JavaBeans were blocks of Java code that could be inserted into web applications. It was Netscape’s response to Microsoft’s ActiveX component model, which had tight integration with the Windows OS. By comparison, JavaBeans were cross-platform. Java was famously a “Write Once, Run Anywhere” programming language; and with JavaBeans, “Re-Use Everywhere” was appended to that catchphrase.
As described in the JavaBeans API specification in 1997:
“The goal of the JavaBeans APIs is to define a software component model for Java, so that third party ISVs can create and ship Java components that can be composed together into applications by end users.”
The spec noted that some JavaBean components “will be used as building blocks in composing applications,” while others will “be regular applications, which may then be composed together into compound documents” (it gave the example of a spreadsheet being embedded inside a web page).
For Netscape, JavaBeans were a convenient way of introducing powerful desktop application functionality into its browser. This was particularly important for enterprise applications, which ran on corporate-controlled networks called “intranets.” This form of app development was a traditional strength of Microsoft, given its OS and office software dominance in the market. Netscape realized that the only way it could compete with Microsoft in enterprise software — and by extension attract more app developers to its platform — was to partner with Microsoft’s competitors in enterprise software, like Sun and Oracle.
JavaBeans enabled developers to access data and functionality in applications outside of the browser, but connected via the intranet — such as messaging, directory, security, publish and databases.
“Currently, developers who provide Java components and objects for crossware applications are mandated to use Applet and related classes in the Sun java.applet package to create an application, and must use the tag to embed the application in an HTML page. While the applet model works well for simple, self-contained Java applications, each such applet is restricted to a single AWT Frame object, runs in the page where it is embedded, and cannot participate in HTML form posting. The applet model does not provide a shared execution context for multiple objects. Finally, applet lifetime is not well-defined, and cannot be controlled by the application developer.”
The Networked Enterprise
A couple of months earlier, in April 1997, Andreessen had outlined his vision for Netscape inside the enterprise. The whitepaper listed a series of code-named services, like Mercury, Apollo and Compass. For example, Mercury was the code name for the next version of Netscape Communicator, “targeted for early 1998.” Unfortunately, at times this came across as buzzword bingo. For instance:
“Apollo is complemented by Palomar, a first-of-its-kind visual crossware development tool that allows complex crossware applications to be quickly and easily designed and deployed.”
There was a creeping complexity, too. Netscape Navigator 4.0, released during DevCon in June 1997 as a part of the Communicator suite, was described as having an “enhanced application environment” in the whitepaper. Among its features:
“Navigator 4.0 builds in a CORBA Object Request Broker (ORB) to support CORBA/IIOP applications and faster Java support across platforms, including Windows 3.1.”
As described in a June 1997 Wired article, Common Object Request Broker Architecture (CORBA) was “a model designed to allow applications to communicate with one another no matter where they are located or who has designed them.”
Netscape’s strategy was to enable developers to build “cross-platform applications that can be deployed on a browser”; but it was unclear at the time how well JavaBeans and CORBA would integrate with Netscape’s browser (let alone competing browsers).
Regardless, in a developer roadmap paper released for DevCon, Andreessen doubled down on the portability and interoperability of its approach:
“Together with CORBA and IIOP, the Internet standards for communication between JavaBeans, it is now possible to develop and deploy service-based applications that are portable, in that they can run on any platform, and are interoperable, in that they can interoperate with each other and leverage a variety of back-end systems and services.”
Although all of this was still relatively unproven in 1997, in hindsight Netscape’s web application strategy set the standard for how all web technologies have been positioned ever since — as cross-platform and interoperable. It’s more true than ever for modern day web apps, in comparison to ‘walled garden’ platforms like Facebook or Apple’s iOS.
In fact, Microsoft had already one-upped Netscape in 1997 with Visual Studio 97, which had been released in January of that year. Such tools were called IDEs (integrated development environment) and Microsoft Visual Studio 97 was the very first version of a product that continues to be offered to this day (the latest version, as I write, is Visual Studio 2019).
Looking back on it over two decades later, 1997 was the year when web development began to get overly complicated. That’s because web applications were the new battleground for the two main browser companies, and each had their own component model and differing view of what “dynamic” web pages entailed.
All of this development divergence meant that browser incompatibility was becoming an increasing source of frustration for web users, a theme we will explore further in upcoming posts.