Content 2.0

When was the last time a Web page written in HTML really wowed you? Chalk up lackluster site presentation to the limitations of the medium itself. The Web's hypertext system of links and tags was designed with information architecture in mind, not graphic design. The earliest versions of HTML didn't support graphics of any kind—it took Marc Andreessen's Mosaic browser to deliver that. Even today, HTML offers scant control over design essentials like typography and screen layout, and does little to accommodate complex interactions between browsers and servers. Making a trip to the server after each mouse click is a fairly inefficient way to deliver information. As Web development increasingly focuses on applications, markup's limitations are becoming more and more apparent.

Concerns like these have given rise to a number of proposed alternatives. Most notable among the current crop are Macromedia Flash MX and the Curl content language. Both Macromedia and the Curl Corporation have positioned their products as superior alternatives to yesterday's plain HTML, and not just for gimmicks and entertainment sites. Both companies are hoping to win converts among the enterprise market as well.

Make no mistake: Ditching HTML isn't for everyone. Sites that are truly trying to reach the widest possible audience are advised to stick with the basics. If you are able to target your audience more narrowly, however, you may want to consider more advanced client-side technologies. Moving beyond simple markup can offer significant benefits, especially for sites with sophisticated UI requirements, or when you want a user experience with a little more pizzazz.

[click for larger image] Lean, sophisticated UIs that provide multiple views of data without burdening the server are Curl's forte. This applet, created for Siements, is only 100KB in size.

Beyond Java Applets

HTML alternatives have been around almost as long as graphical Web browsers. Java was among the earliest technologies for developing rich browser-based interfaces, and in many ways, Sun nailed the formula for Web-distributed applications dead on. Java applets were highly functional, secure, robust, and deployable across myriad platforms. But despite its promise, Java has never really managed to displace traditional, HTML-based interfaces for a number of reasons.

For one thing, Java applets are slow, a situation that's only really been remedied as CPU speeds have increased. And despite being marketed as a "write once, run anywhere" language, getting the same applet to deliver a consistent user experience across different browsers and platforms has always been a challenge. In many cases, an applet might have worked in Internet Explorer for Windows, but simply wouldn't run anywhere else.

Worst of all, as a full-fledged object-oriented programming language comparable to C++, Java development was just too complicated for those whose primary background was in design. Today, the technology seems to have found its niche on the server side, an environment much better suited to hardcore programmers who can truly make use of Java's many features. But this has left many client-side developers searching for other options.

One answer to Java's clunky UI is Macromedia Shockwave for Director, a complex browser plug-in derived from technologies developed for the multimedia CD-ROM market. Shockwave developers create applications using a proprietary language called Lingo, which offers numerous audio, video, and animation capabilities. Lingo wasn't really designed with enterprise application development in mind, however. As such, Shockwave has always been better suited to animation, multimedia content, and gaming—areas where it still enjoys a strong hold on the market.

The Macromedia Alternative

Macromedia Flash, introduced in 1997 as a follow-up to Shockwave, has proven wildly successful, far surpassing the popularity of its predecessor. Flash began simply as a way to bring scalable vector graphics, like those created in Adobe Illustrator or Macromedia FreeHand, to the Web. But each new version of the plug-in has brought Flash closer to becoming a full-fledged client-side application development tool. The current release, Flash MX, represents Macromedia's first serious bid to give Web designers a real alternative to UIs created in HTML.

As with Shockwave, viewing Flash content requires a browser plug-in. But unlike its older sibling, the Flash Player has stayed lean and mean, even as its feature set has grown. Flash's small footprint, combined with Macromedia's shrewd volume licensing deals, has made it nearly ubiquitous in the Web browser market. What's more, Macromedia has recently started to move Flash off the desktop and onto consumer devices. Nokia Communicator cellular phones, Pocket PC handhelds, and Sony's PlayStation 2 console all support the format. Plans for ports to Palm OS, TV set-top boxes, and other devices are in the works.

What makes Flash more than just another media type, however, is ActionScript, a lightweight programming language that gives Flash developers capabilities similar to those of Shockwave's Lingo scripts. ActionScript is derived from the ECMA-262 standard, which means that it closely resembles other ECMA-262 languages, like JavaScript and JScript. In addition, Macromedia provides a number of preprogrammed functions with Flash MX, making ActionScript programming largely a drag-and-drop affair for UI designers who don't want to muck around with scripts.

Advanced Flash Scripting

If you're not afraid to write your own code, you'll find that ActionScript differs from JavaScript in several ways. It uses a different document object model (DOM), one that's tailored to suit Flash's movie clip metaphor. It also lacks certain features, such as regular expressions. Again, capabilities like these were left out in the interest of keeping the Flash plug-in small.

In previous versions, Flash was more or less a fancier version of HTML. Flash content was rendered in the browser window, and it could be manipulated with ActionScript in much the same way that JavaScript can be used to control the display of HTML. But talented Flash developers have recently been pushing ActionScript's limits, writing game servers and even implementing XML-RPC within Flash.

Flash MX raises the stakes still higher, with the addition of a technology called Flash Remoting. In the past, you would have needed to call a CGI script or ASP page to access a SQL database from a Flash movie, but Flash Remoting lets the same Flash movie call server-side database access methods directly. What makes this possible is the tight integration of Flash MX with ColdFusion MX and JRun 4, the application server products Macromedia acquired from Allaire in 2001. Additionally, Flash MX allows developers access to Web services via the SOAP protocol.

With the recent release of Flash Communication Server MX, Flash gains still more collaboration capabilities, including multi-way streaming audio and video. Macromedia's product developers are betting that these features will make it even more attractive to the enterprise application development market—and they might be right. If you've grown accustomed to thinking of Flash merely as an animated graphics format for creating extravagant site-intro screens, it's time to give it a second look.

Surfing the Curl

Macromedia isn't the only company marketing alternative content formats for the Web. A relative newcomer to the field is Curl, developed by MIT research scientist David A. Kranz. Curl is notable for having won the endorsement of Tim Berners-Lee, the inventor of the Web, who in 1998 became a cofounder of Curl Corporation with Kranz and eleven other MIT colleagues. The company released its first product in 2001, and earlier this year it launched its first commercial campaign aimed at the enterprise market.

While Flash was conceived (at least initially) as a way to render advanced onscreen graphics, Curl takes a slightly different approach. Rather than simply augmenting the current HTML model with more sophisticated types of content, Kranz and the other Curl engineers sought to address the inherent inefficiency of Web-based applications. Today's Web tends to revolve around the server, with the browser merely used to display the results of server-side operations. In Kranz's vision, the client computer takes on more of the processing burden, reducing the load on server and network resources.

If you think about it, this approach makes sense. Today's desktop PCs have power and CPU cycles to burn. Why not apply those resources to network-delivered applications? Curl also lends itself to more responsive UIs than HTML allows. Rather than refreshing the page from the server each time a user wants to switch from a bar graph to a pie chart, for example, a Curl interface can present multiple views of the same data without relying on the server to re-render the content.

Another benefit of Curl is that it was designed from the ground up for rapid application development. Curl developers boast of creating prototypes in hours, rather than the days it might take to build a functioning Java applet.

Coding for the Client Side

Because it is fundamentally a programming language, Curl caters more to application engineers than it does to designers. Rather than adhering to the rigorous object-oriented programming conventions of Java or C#, however, Curl uses a compact syntax that borrows some of the semantics of HTML. For example, bare text is automatically rendered as text onscreen, just as it would be in an HTML page.

The heart of the Curl system is a browser plug-in called the Surge Runtime Environment (RTE), currently at version 2.0. The Surge RTE works something like the Java virtual machine or Microsoft's common language runtime, compiling and executing Curl code on the fly as it's downloaded from the network. Curl differs from Java or C# in that the server sends data to the client machine in raw source form, rather than as preprocessed byte codes.

Also unlike Java (but more in keeping with C#), Curl runs only on Windows. That may not be a problem, however, if you consider Microsoft's almost total dominance of the corporate desktop. Since the primary market for Curl, at least initially, is likely to be the corporate intranet, standardizing on Windows shouldn't be much of a liability. If anything, it should allow Curl engineers time to concentrate on maximizing the performance of the Surge RTE, which can be sluggish on low-powered machines (though not as slow as early Java applets).

Closed Content?

For content developers looking to escape the restrictions of HTML, both Flash and Curl offer compelling advantages. Yet there are other factors to consider before making the leap to a new Web content platform. Are eye-catching graphics your main concern, or is your goal to create a sophisticated interface for your back-end applications and data? Who will be primarily responsible for developing your site: designers or engineers? Each of these factors should weigh heavily on your ultimate decision.

Perhaps the most important point to consider is the proprietary nature of these solutions. Though Flash product literature dubs it an "open standard," in truth Macromedia alone controls the format's future direction. Likewise, Curl Corporation makes no bones about its total ownership of the Curl language. Past versions of the Curl license actually sold content "by the pound"—the more Curl content you served, the more you had to pay. The company has since abandoned this structure in favor of more traditional per-seat, per-site, and per-application licensing. But unlike the Flash Player, the Curl client plug-in remains a for-pay commercial application. Prices start at $25,000 for the Enterprise Starter Kit, though free evaluation copies are available on Curl's Web site (www.curl.com).

Licensing issues aren't the only risks you face when choosing a proprietary content format. Reliance on proprietary plug-ins can also leave your content susceptible to product upgrades that can break your existing pages. It could also leave you high and dry should the plug-in vendor go out of business, or should your user base move to an unsupported OS.

Whether these are risks worth taking will depend on your individual project. How critical is your immediate need for an alternative UI development tool? How skilled is your staff in using the new technology, and how much training will be required? Is there a clear migration path away from the closed format, should circumstances require it?

Fortunately, none of the alternative Web content formats requires a wholesale commitment up front. All of them coexist well with traditional HTML and back-end applications, leaving plenty of opportunity for a gradual transition. So go ahead and experiment. If you've been laboring under the assumption that plain HTML is a fact of life for serious Web development, you might be surprised to discover just how versatile today's online content can be.

Neil is New Architect's senior technology editor.