Web Techniques: The Client-Side Conundrum

CD Home < Web Techniques < 2000 < August

The Client-Side Conundrum

By Ray Valdés

The ratio of attention that developers devote to browsers and client-side technologies has shifted over the years. In the early days the browser got more attention when crafting the end-user experience, because most sites had simple server-side configurations. A couple of years ago, the focus shifted to server-side technologies like application servers and dynamic publishing systems.

One of the largest battles in the browser wars was between Java applets and ActiveX. This conflict got a lot of press even though the number of sites that actually used ActiveX controls was very small (probably one fiftieth of the number of sites that incorporated Java applets).

No need to get into the details of such dead-end experiments. But it's worth noting that, although the hidden agenda was world dominance, there was also a more valid rationale: better control of the presentation and formatting of content to enhance the impact of HTML pages. Of the many vendor-specific browser extensions that were introduced in the late '90s, some proved genuinely useful like tables, frames, and JavaScript. Over time, the tags that developers used most were adopted into the mainstream Web platform.

My intent is not to pay homage to old events but to point out a deep-seated dynamic that still exists. There's an ongoing conflict, not between two browser vendors, but between two camps in the Web developer community that I'll call the progressives and the fundamentalists. The progressives, easily captivated by the latest technological trinkets, are early adopters of technologies regardless of whether they represent genuine advances. The fundamentalists resist adoption of a technology until it has proved to enhance the user experience.

The way Java applets quickly appeared on the scene and then withdrew over time illustrates this dynamic. Many progressive developers were dazzled by the promise of a client-side technology that was designed to be secure, portable, efficient, and more powerful than the primitive user interface mechanisms in straight HTML. These enticements obscured the reality of slow, buggy applets that behaved differently on different platforms. One developer I know did all Java development on the Macintosh because that was the only way to make sure Java code would run on different platforms. If you wrote the code first on Windows and then tried to port it to the Mac, you couldn't get it to work; but if you tried it from the other direction, you had a fighting chance at producing portable code.

Those who lived through that time still have an instinctive reaction to seeing two dreaded words on the browser status line: "Starting Java..." The message meant that your smooth surfing experience was about to come to a screeching halt while the browser loaded the Java Virtual Machine (JVM). Everything stopped while the JVM loaded, including actions like switching windows, choosing menu items, and scrolling down the page. The normally responsive system turned its back on the user.

Lessons Learned

JavaScript is another promising client-side technology that appeared quickly and then receded for a while. JavaScript promised a lightweight, portable, interpreted language that could create dynamic behaviors that Java or ActiveX couldn't. Because of JavaScript's tight integration with the browser environment and internal data structures (the Document Object Model), developers could turn menus on and off dynamically, inject arbitrary HTML into the document at run time, and write to the status line in the browser window. Naturally, early adopters went overboard. Many inserted useless messages that scrolled across the status line and often crashed the browser.

In its early implementations, JavaScript was a paradox. It was easy to learn but hard to program because of bugs and incompatibilities between versions. It was small but less portable than larger and more complex systems like Java. This wasn't because of inherent architectural flaws in JavaScript, but rather because JavaScript was an afterthought in Netscape's initial strategy. It was the work of one developer who had other things on his plate.

Yet, JavaScript became more robust and powerful with each browser version. Web developers eventually put together a small repertoire of JavaScript techniques that worked across multiple browser versions and performed simple functions like image rollovers and data entry validation. Such technical know-how, often based on trial and error experiments, contributed to a fast-growing aura of conventional wisdom surrounding client-side technologies. Today, this wisdom is often summarized by a number of best-practice maxims like:

Limit page sizes to 60KB.
Limit the amount of moving elements on the page.
Test pages with both old and new browsers.
Avoid ActiveX entirely.
Use Java applets only in exceptional circumstances.

The last two items on the list might suggest that Java won the battle with ActiveX, but in truth, neither side won. If you look at the top sites on the Web ranked by number of visitors (for example, the Media Metrix list of Top 500 sites), you'll find an inverse correlation between the use of client-side technologies and the site's success. The topmost sites like Yahoo and Amazon are scrubbed clean of client-side technologies like Java, ActiveX, and JavaScript. They've found that these technologies detract from user experience instead of enhancing it. Statistics show that users prefer sites that load fast, are easy to navigate, and don't exhibit anomalies when viewed with different browsers.

Tracking Patterns

This doesn't mean that developers have stopped using client-side technologies altogether. It just means the technologies are less visible—and less obtrusive—to the average user now. I wrote a script that crawls the sites on the Media Metrix Top 500 list to catalog the technologies that each employs. My program retrieved HTML files from each site's home page and parsed them, looking for script tags and other indicators of client-side technologies. The results are in Table 1, displayed in order of market penetration.

As you can see, there's widespread use of tables for positioning. That's reasonable, as many developers have given in to the fact that well-designed pages often have elements that need complex positioning. JavaScript is used on more than 60 percent of sites surveyed. Further down on the list are client-side imagemaps, and style sheets, with Java applets and ActiveX objects at the bottom.

The data in the table represents a snapshot in time of a particular population of sites. I've been observing this population for the past 18 months and have witnessed a number of changes in the statistics. Table use has remained near 80 percent, which is probably the saturation point. JavaScript usage has increased steadily from 40 percent to over 60 percent, despite the fact that the very top sites eschew this technology. Similarly, style-sheet use more than doubled from 8 percent.

Java applets and ActiveX objects are still at the bottom of the list.

Breathing New Life

If there were so many lessons to learn from rapidly adopting client-side technologies, what could explain the jump in JavaScript use? After looking into some of the sites on the Top 500 list, I came across a number of new companies that are breaking all the rules. Many are building large Web applications that use hundreds, if not thousands, of lines of client-side JavaScript code.

How do they get away with it? Surprisingly, returning number-crunching to the client side is more sane than it seems. In almost all the cases, the companies use JavaScript to implement richer, more dynamic interfaces than are possible with pure HTML. User interfaces on some sites now support dynamic pull-down menus, drag-and-drop capabilities, scrolling windows, pop-up dialog boxes, icon-based manipulation, and so on—all things that can enhance a user's experience if employed properly.

There's a new category of sites that aggregate content and function for end users. These aggregator sites, sometimes called metabrowser sites or screen-scrapers, let end users build personal portals or pages composed of pieces of existing sites. (For a list of those sites and others mentioned in this article see " Online.") The aggregators recognize that users don't necessarily like everything on a site, whether that site is Yahoo, CNN, or Salon.com. The aggregator sites interpose themselves between the user and his or her destination sites. Aggregators let a user pick headlines from Yahoo, stock portfolios from Quicken, and discussion-forum summaries from Salon, then assemble these disparate pieces into a single dynamic page, providing a greater degree of personalization than that offered by a single site. There's a lot of server-side magic involved in page element retrieval and assembly; but these aggregator sites have user interfaces that include sophisticated JavaScript controls.

Can It Last?

Is this the beginning of a new era in client- side technology, or the last gasp of a dead-end technology? Time will tell. There are some powerful driving factors behind this recent client-side explosion. First, Internet Explorer came away from the browser wars with dominant market share. Second, JavaScript has matured and become more standardized, reducing the incompatibility problem. Finally, the growing number of cheap new PCs with preinstalled browsers means that older, noncompliant browsers are being retired.

Adventurers who'd like a return to the days of heavy client-side scripting will have to be extremely careful not to repeat past mistakes. The cautionary tale of London-based Boo.com serves as an example of what can go wrong when technology gets out of hand.

Europe's largest startup, Boo was an e-commerce site selling high-fashion clothing. Boo encountered the classic problems that have plagued software development for the last 40 years: project delays, bugs, performance problems, poor user interface design, and so on. But the log that broke the camel's back was an over-enthusiastic reliance on client-side technology.

The Boo interface had multiple JavaScript pop-up windows and 3D animations so prospective customers could view an article of clothing. This meant large pages that took forever to load, and a majority of users couldn't view the pages. Customers in Europe—a region that has less cable-modem and DSL penetration than the U.S.—were even more frustrated, especially because many Europeans pay for access by the minute rather than paying a flat rate.

Today's crop of client-side technology deployment is so new that the market hasn't had a chance to speak. It's difficult to say what the future holds for such sites, but one thing I can say with certainty is that there will be many more failures before one of these client-intensive sites cracks the Top 10 list.

Ray is VP of engineering for MyPersonal.com, a provider of portal technology services to affinity and membership organizations. You can reach him at rayval@mypersonal.com.