Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Plug-Ins? Opt Out!

Plug-ins can't rival Java as an option for developing distributed software

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

Page 2 of 3

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?

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources