Plug-ins can't rival Java as an option for developing distributed software
Netscape has done much to advance the state-of-the-art of the Internet. But it is not the home of altruism. It’s plug-in strategy is great for Netscape and a host of Internet wanna-be vendors, but dangerous for most software developers.
Summary
In the last issue of JavaWorld (“Netscape: Ship of fools?”), Rayme Jernigan wrote about the potential dangers inherent in Netscape’s strategy for adding functionality to its browser via third-party plug-ins. This may well turn out to be one of the most important issues facing the Java community and deserves some further discussion. Plug-ins may be useful for rendering specific content types, but cannot rival Java as an option for developing distributed software.
Religious warfare
In the global struggle for Internet dominance, two religions are waging war. As in any conflict where lives, careers, and fortunes are at stake, both sides assert the righteousness of their cause and claim that God is on their side. Scholarly tomes will be written about the struggle between Netscape and Microsoft; the press will create new champions daily and then destroy them, and each new struggle will become a deadlier form of jihad.
The basic doctrine of each side is easy to discern. Netscape, like many others in the world, views Microsoft as the Great Satan — an evil monopoly whose desktop dominance has stifled innovation and been sustained by unfair business practices and insidious intent. Microsoft views itself as a democratizing force, one who has brought computing to the masses with ever-increasing functionality at ever decreasing prices. Netscape’s agenda is to write a new network operating system with universal clients (browsers) and universal programming languages (HTML, Java and JavaScript) for applications that can scale from workgroups to the universe. Microsoft’s plan is to leverage its existing dominance in desktop content by tightly integrating its software (such as Excel, Word, and Powerpoint) into its Internet environment along with Windows, Visual Basic and ActiveX so that the Internet is a natural extension of its existing proprietary operating system.
However, while the crusading armies skirmish, software developers must write software. Smart developers will write agnostic software, not adhering strictly to the tenets of either side. Being a successful agnostic means being skeptical about any technology that binds one to the belief system of any particular religion. While the self-serving dogmas of Microsoft are always well documented, Netscape has so far managed to position itself as a vendor of altruistic software, unfettered by religious bias. However, what it is marketing is a very seductive ideology, and the plug-in part of its strategy has the potential to send unwary developers to a hot and painful place.
Plug-ins lead to fat clients
Plug-ins are a great idea for Netscape but a bad idea for most software developers. For a developer of a new network operating system (like Netscape), a plug-in strategy permits the leveraging of outside developers to write interesting features that the vendor cannot afford to write itself. It allows Netscape to bundle the most attractive plug-ins into its standard software, while maintaining the holy ground of embracing open standards. Plug-ins are also good for vendors of Internet wanna-be software. By duplicating their Windows or proprietary runtimes in a Netscape plug-in, a wanna-be can say that its software is “Internet Enabled.” The reality is that as a foundation for distributed applications, plug-ins can be a nightmare for developers of both Internet and Internet software, for a number of reasons.
Plug-ins can easily result in fat clients. Many programmers familiar with the existing market for client/server development software are anxious to use Internet technologies to realize the promise of truly scalable software. One of the main reasons for this desire is the fact that popular client/server tools like PowerBuilder tend to require large, fast and expensive clients. In the corporate world, a client must be a Windows machine with additional memory and disk space for the interpreter and runtime environment of the specific software development tool. This environment can add up to 16 megabytes of memory to every client that must run the application.
Corporate intranets are attractive to companies because they promise to use a much smaller and inexpensive client environment — a standard Web browser. But using plug-ins defeats the promise of thin clients by adding additional baggage on top of the native operating system of the client and the browser. In many corporate Windows environments, a browser-based application utilizing plug-ins requires more client resources than the client/server application it replaced.
The situation is even worse beyond the firewall and into the Internet. While it is conceivable that a company may wish to invest in a consistent fat-client environment, it cannot mandate this platform for its customers, vendors and suppliers. Applications written for fat intranet clients are unlikely to work outside the enterprise. Nor will these applications run on the low-cost Internet appliances that are on the horizon.
The terms “plug-in” and “fat client” have become synonyms. (Just as Internet Enabled has begun to mean Internet Enfeebled.)
Plug-ins are a maintenance nightmare
Let’s suspend our disbelief for a moment, and assume that a company is willing to invest enough money to buy a set of robust client machines in support of its plug-in-based intranet application software. One of the other great problems with existing client/server development approaches is the requirement to maintain a consistent set of software across all available clients. To execute predictably, each client system must use the same operating system release and same release of the client/server tool’s interpreter and/or runtime. Maintaining and updating such an environment has proven to be expensive and difficult for most corporations Again, many companies are designing Intranets using standard browser technology in hopes of solving this problem.
However, a plug-in based strategy is even worse than the existing homogeneous Windows environment that exists in many corporations. In addition to maintaining a consistent computing platform, or set of platforms, IS managers must maintain a particular browser type with a compatible set of plug-ins. Employees or other users who wish to access an application must have the same set of plug-ins and use the same browser.
The situation only gets worse when applications must run on nomadic devices or in more than one language. Does the plug-in assume resources are available on a network? Will large plug-ins be downloaded over the network, will they be shipped on CD-ROM? Will they work in my local language?
Who is responsible for maintaining these extended browsers: the individual? the vendor? the corporate IS department? Who pays for the plug-ins? Who does the support? Ultimately the corporation will pay, and the IS department will maintain the software. Finding the vendor responsible for a bug in an application running on Windows machine using a Netscape browser with Powersoft and Macromedia plug-ins will be an interesting challenge for the help desk of the future.
Portability and platform-specific plug-ins
Perhaps the nadir of the plug-in strategy will become apparent when Microsoft releases version 3.0 of its Internet Explorer this summer. One of the promises of I.E. 3.0 is that it will allow a user to view live desktop content like Excel spreadsheets. The Microsoft plan of record is unabashedly homogeneous; this content will run in the Microsoft browser on the platforms it currently supports, namely Windows and Macintosh.
There is bound to be a Netscape plug-in somewhere on the horizon that will attempt to do the same thing. Of all the bad ideas in the world, mimicking the performance of a proprietary computing environment via a plug-in on a foreign platform must rank in the top ten.
The promise of writing truly portable software is not a attained by trying to artificially recreate a standard operating system environment on foreign platforms. A number of abandoned efforts litter the landscape — Windows accelerator cards on Unix machines, co-processors, and WABI, to name a few. Computing environments are different, and finding a universal one requires having a fresh start with something common on many platforms, not emulating an existing one on others.
Writing agnostic software
The future of computing will almost certainly continue to involve multiple choices. The best way to write software for a heterogeneous computing environment of multiple browsers, on multiple operating systems on multiple computers is with HTML and Java. True agnostics should have no emotional attachment to either of these languages beyond a simple recognition that they are the best things that exist today and hold the most promise for the future.
Every indication is that Java will be all-pervasive, not just in browsers but in operating systems as well. Plug-ins may provide a compatible client environment for some applications, but server support is and will be nonexistent. Support for Java at the operating system level has been announced by Microsoft, IBM, Apple, and most Unix vendors (including Sun, of course). these developments promise Java on the both the client and server, providing a seamless programming environment that is unequaled.
Brave developers who wish to move down a plug-in route should use them only to render specific content types like VRML or MPEG. Plug-ins are a dangerous, expensive and maintenance intensive path for most other uses.
The Reformation has begun, and there may never be another dominant computing religion comparable to Microsoft Windows and DOS. For the near term, there will be at least two reigning world views: Those of Microsoft, and those and Netscape. Intelligent programmers will write agnostic software that distinguishes between important advances in the state-of-the-art and dangerous religious dogma. Successful programmers will write to common specifications whenever possible, and avoid metaphysical diversions. Plug-ins, for all their seductive glamour, clearly fall in the latter category.
