For years those hurdles were more like roadblocks. Application vendors couldn't commit fully to writing Web-based applications because good development environments were nonexistent; programming-language and scripting support was pathetic; good developers were hard to find and even harder to keep; and browsers were not only immature but, unless you added myriad plug-ins to bolster their anemic feature sets, nearly useless for anything other than displaying HTML. Understanding why Web-based application development was half-hearted at best is easy, especially when you compare its state of affairs with that of the feature-rich and mature 32-bit Windows development environments, robust language choices, and legion of able and willing developers with years of experience available then.
Still, industry veterans were confident that over time the roadblocks to Web application development would be removed, and they were right. However, there were both good and not-so-good reasons for this shift. The best reason was access, followed closely by technological advances. Deployment of 32-bit Windows applications was difficult at best for in-house employees, a nightmare for remote workers, and impossible for the hundreds of millions of customers and partners the e-business community needed to reach. The Web was the biggest thing to hit computing during the '90s, going from zero to global in eight years. Access was as close to ubiquitous as we were likely to get. Hundreds of millions of users made it their business to ensure they were equipped to execute Web-based applications from the comfort of their homes. And OS-centric applications were not cutting it in this brave new wired world.
The biggest misconception was that browser-based applications would eliminate platform incompatibilities. The reasoning was that if an application were Web-based, it would run on any browser on any platform. The truth of the matter is that even browsers from the same vendor don't behave the same way on different platforms -- just take a look at how Microsoft Corp.'s Internet Explorer (IE) 5 or Netscape Communications Corp.'s Navigator 4.7 run on a Macintosh compared with how those browsers run on a PC. And if you support IE on your PCs and Navigator on your Macs and plan to run the same application on both, we feel for you.
Web application vendors have gotten good at masking these incompatibilities, but platform differences still increase development costs and reduce feature sets because the lowest common denominator must be considered. As if this weren't bad enough, WML (Wireless Markup Language)-based browsers now exist on form factors as small as cell phones and PDAs -- it's a whole new ballgame out there. (For a full description of WML and the challenges it brings to the plate, see our WML report exclusively online.)
Right Idea, Wrong Reasoning
Forward-looking CIOs would have been more on the mark if they had cited reduced deployment costs as a reason to move forward with Web-based applications, even though full-featured Web applications often shipped with plug-ins that rivaled fat clients for complexity and carried their own deployment headaches. Today, advances in browser technology have let developers dramatically reduce or even eliminate application-specific plug-ins (see "In the Trenches With eRoom").
Because of the careful oversight of the World Wide Web Consortium (W3C), along with contributions from Microsoft, Netscape, Sun Microsystems and a number of other companies, the wide gap between Windows development and Web development has narrowed. Web developers have finally gained ammunition for their guns in the form of standards-based tools, such as CSS (Cascading Style Sheets), DOM (Document Object Model) and XML (Extensible Markup Language). Even lowly HTML has been improving steadily, with the latest W3C recommendation marrying HTML and XML to arrive at XHTML (Extensible HTML). XHTML brings modularization and a level of device independence to the browser-based dance (for more on XHTML, see "XHTML: Crossroads of HTML and XML").
>> Cascading Style Sheets. CSS imposes order on document presentation by giving Web authors document-independent control over fonts, spacing, margins and backgrounds, from style sheets embedded in individual HTML pages or via master style sheets referenced with a URL. This lets developers control the look and feel of an entire site or of an entire Web application. When used correctly, CSS can make documents look good on browsers running at resolutions from 640x480 and up without needing special code for each resolution. Some level of CSS support was included in browsers starting with IE 3 and Navigator 4, and compliance has improved steadily with later releases. CSS Level 2, the current W3C recommendation, was approved in May 1998, and CSS Level 3 is available as a working draft (see www.w3.org/TR/css3-selectors/).
>> Document Object Model. DOM provides the mechanisms for developers to build dynamic, interactive Web pages. As defined by the W3C, "The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed, and the results of that processing can be incorporated back into the presented page." DOM and DHTML (Dynamic HTML) are often referred to as the same thing -- or worse, as two different things. It's more accurate to say that DHTML represents the use of scripts to operate on the document objects exposed by the DOM built into your particular browser. Clear as mud? Peter-Paul Koch, a Web developer, provides an excellent resource for helping developers understand DOM, and he has done extensive testing with a variety of browsers to determine levels of compliance (see www.xs4all.nl/~ppk/js/index.html?browsers.html).
>> Extensible Markup Language. XML has emerged over the past couple of years as LDAP's successor in the always-coveted, ultra-hyped technology award category. The difference between XML and LDAP, where hype is concerned, is that lots of companies will benefit from the standards-based data interchange made possible by XML, while LDAP is still looking to make a visible mark on anything.
In the years to come, XML will become known as the great slayer of the import/export menu option on your favorite stand-alone business application. In addition, XML will provide the mechanism for that stand-alone application to join the business-to-business and business-to-consumer party.
Stay Tuned
Is a Web-based application always the right choice? No. Given current technology, it wouldn't make sense to develop a full-featured spreadsheet or word processor as a browser-based application. The user controls are too complex, and way too much client-side processing is required for this type of project to be successfully implemented in a browser. Just look at Corel's efforts with Corel Office for Java -- doomed from the start with more than 4,000 individual Java applets! However, given the tremendous improvements in browser technologies, we wouldn't be surprised to see even these limitations eradicated over the next couple of years.
Send your comments on this article to Ron Anderson at randerson@nwc.com.
REPORTS
ANALYTICS
Follow 
