Choosing the Right Technology

If you are a Web developer, you face a bewildering number of options for creating business solutions that run in a browser. Competing technologies present a confusing picture as you try to select a suite of tools for your project. This section examines some of the key issues involved in Web-based solutions and provides guidance in the selection of technologies for creating an application.

Client Platform Considerations

Without question, the single biggest concern in technology selection is the target browser. You must identify the various browsers you will support with your solution. If the application is intended as a public Internet solution, look to the widest possible audience. That does not mean that you must accommodate every type of browser. If you try to do so, you are limited to simple HTML pages with no frames or tables. A solution written to the lowest common denominator offers little functionality or visual appeal.

In most cases, support for Microsoft Internet Explorer and Netscape Navigator should be sufficient to reach over 90 percent of the intended audience. However, different versions of these browsers support different technology levels. If your application has to support an earlier version of IE or NN—one prior to version 3.0—some of the newer technologies might not work. And even limiting the scope of the solution by version might not be sufficient to solve the problem. Operating systems can affect the equation as well. For example, IE 3.0 running under Microsoft Windows 3.11 does not recognize the <OBJECT> tag.

Obviously, target platforms become the primary focus of technology selection. The following table shows some popular browsers and their capabilities.

Browser	HTML	Cascading Style Sheets	Dynamic HTML	Scripting	ActiveX	Java
Internet Explorer 4.0	3.2	Complete	Yes	VBScript JScript	Complete	1.1
Internet Explorer 3.0	2	Format support only	No	VBScript JScript	Complete	1.0
Netscape Navigator 4.0 (Communicator)	3.2	Complete	Yes^*	JavaScript	Active Documents	1.1^**
Netscape Navigator 3.0	2	None	No	JavaScript	None	1.0
Netscape Navigator 2.0	2	None	No	JavaScript	None	1.0

* Dynamic HTML is implemented differently in Communicator than in IE 4.0.
** Communicator supports partial implementation of Java 1.1, with complete support promised.

You could examine endless combinations of browsers and operating systems, but let's focus on the most common solutions and consider suggestions for creating wide-ranging applications. For the sake of discussion, assume that a platform-independent solution means an application that can be used by Internet Explorer and Netscape Navigator versions 3.0 and later. Even in this limited domain, you'll find plenty to be concerned with.

HTML Support

Within your limited field, all the browsers you are targeting support the latest HTML 3.2 standard. This does not mean that you can use any HTML tag. Many tags are not part of the HTML standard and are simply proprietary to a particular browser. The <LAYER> tag in Netscape Navigator 4.0 (also known as Communicator) is a good example of a tag not supported by any other browser. <LAYER> is used to create invisible layers of HTML content in the Communicator version of Dynamic HTML. However, if you limit yourself to the HTML 3.2 standard and stay away from proprietary tags, all the target browsers should support your content.

Cascading Style Sheets

Cascading Style Sheets (CSS) were introduced under Internet Explorer 3.0 and were enhanced under IE 4.0. Communicator introduced CSS support for Netscape browsers. IE 4.0 and Communicator accommodate the complete CSS specification, including positioning elements through left, top, height, width, and z-index attributes. Under IE 3.0, CSS support is limited to font attributes such as size, color, and style and does not include advanced content positioning.

Dynamic HTML Support

Dynamic HTML is, of course, a new feature of Internet Explorer 4.0 and is not supported in any previous release of IE. Netscape Communicator also supports a version of Dynamic HTML, which can lead to confusion regarding the implementation of this technology. Although Netscape uses the same name for its dynamic positioning technology, the technology itself is fundamentally different from Dynamic HTML under IE 4.0. Under Communicator, you create layers of content that can be moved and sized dynamically. These layers can be created by using a <STYLE> tag with a position attribute set to ABSOLUTE or by using the proprietary <LAYER> tag.

Although you can create effects in Communicator that are similar to effects in IE 4.0, you will have an extremely difficult time creating an application using Dynamic HTML that runs under both IE and Communicator. At this time, the World Wide Web Consortium (W3C) is considering standards for Dynamic HTML that might eventually bring the two browsers closer together, but the Dynamic HTML issue illustrates a larger truth: competition has left little motivation for companies to agree on any content generation standards. Look for this trend to continue.

Scripting Support

Here the choice is clear. If you want to use client-side scripting in both Microsoft and Netscape products, you need to use JavaScript, which is recognized by all the target browsers. Bear in mind, however, that Internet Explore's JScript does not contain the same level of case sensitivity as Navigator's JavaScript.

Internet Explorer also differs from Netscape Navigator in the implementation of its browser object model. Generally speaking, the object model of IE 4.0 is far richer than that of any other browser, but most of this model is used to tie scripting to Dynamic HTML. Therefore, if you use the browser object model beyond the simple Window, Document, and Form objects, be careful to ensure that the script runs on all target platforms.

Also note that some third parties have created plug-ins for Navigator that allow some support for VBScript. The best known of these comes from N-Compass Labs. Although a plug-in can be useful, users might not have the plug-in when they reach your site and presumably would be forced to download it prior to viewing any content that required it. Forced downloading is time-consuming.

ActiveX Support

This area might surprise you because Communicator offers some level of support for ActiveX technologies. Communicator has the ability to host documents from applications such as Microsoft Word and Microsoft Excel through Automation. The feature allows you to make documents a part of any site that targets the browser. However, any Navigator version prior to Communicator will not support ActiveX documents. Additionally, some literature advertises that Visual Basic ActiveX documents can be viewed in Communicator. At this writing, we can find no such support in the product.

Java

Java is another area where support is widespread. But note that Internet Explorer version 3.0 and Netscape Navigator version 3.0 support only version 1.0 of the Java Development Kit (JDK). The most recent release of Java, which is version 1.1, is fully supported only by IE 4.0. Communicator provides only partial support for JDK 1.1, but Netscape promises full support by the end of 1997.

After examining the difficulties confronting developers who target a wide audience, you might feel that you are left with only HTML 2.0, JavaScript, and Java 1.0. But the truth is that the best solution targets optimal features of all the target browsers. The key to optimizing any solution you create is to use the Browser Capabilities component of Active Server Pages. (The Browser Capabilities component is discussed in Chapter 5.) Finally, test your site in every version of the browser you expect to support. You absolutely cannot guarantee that the site behaves correctly without multiple-platform testing.

Server-Side Considerations

Platforms that can function as Web servers fall into three categories: Windows, non-Windows, and Internet Service Providers. The Windows platform is obviously the tool of choice for the back end of any Web application. Active Server Pages is available only from Microsoft under the Windows platform (although third parties have created versions for other systems). The problem arises when you cannot use Windows, Internet Information Server, and ASP as a back-end solution. In this case, you need to be aware of other available technology.

Even without Windows, IIS, and ASP, you can still use many of the client-side technologies described in this book. Non-Windows platforms can download client-side script in either VBScript or JavaScript. You can also use client-side ActiveX components. Even though the server might not understand the components, the browser can still request a file download, so all you have to do is make the files available on the server and Internet Explorer can use them. Java is also still effective. Once again, as long as the files are on the server, the browser can retrieve them. What you lose with non-Windows platforms is the ease and performance of Active Server Pages. You will probably be left with older, slower technology such as Common Gateway Interface (CGI).

If you are using an Internet Service Provider (ISP), client-side technologies are still available. As long as you can upload script, DLL files, and CLASS files, you can use VBScript, JavaScript, ActiveX, and Java. Some ISPs even support ASP on their server. Check with your ISP to see which technologies are used on the server and whether they are available to subscribers.

Conclusion

Selecting a technology is a function of many different factors. You must decide whether your application will run on the Internet or on an intranet. You must identify your infrastructure support and determine whether you can use ASP as a back end. You should also consider existing knowledge and code investments. If, for example, you have seasoned Visual Basic programmers at your shop, training them in Java might not make sense. Additionally, existing code can be reused in your Web solutions. You might have existing ActiveX controls that could be used in Web pages or Visual Basic forms that could be easily converted to ActiveX Documents. All in all, no simple answers exist, and the pressure of competition promises to prevent true cross-platform solutions for years to come.

Epilogue