[FoRK] [Infoworld] KnowNow as part of what's "after AJAX"

Rohit Khare rohit at xent.com
Thu May 26 11:17:01 PDT 2005


Seems like Austrailia jumped the gun on the news package you can  
expect to see in next week's infoworld: http:// 
www.computerworld.com.au/index.php/id;982499014;fp;16;fpid;0

The sidebar below was my contribution; the rest of the article is  
quite useful and copied below as well

Rohit

> What's next after AJAX
>
> The rapid spread of the term AJAX (Asynchronous JavaScript and XML)  
> -- from Weblog to Wall Street Journal within weeks! -- might lead  
> developers to assume it's a breakthrough that heralds the death of  
> desktop applications. There's certainly a kernel of truth in that:  
> The recent spate of new Web applications under the AJAX banner have  
> redefined end-users' expectation of what's even possible within a  
> Web browser by offering smooth scrolling, incremental updates, and  
> more responsive input forms (see " AJAX breathes new life into Web  
> apps").
>
> Nevertheless, so-called fat-client UIs still retain one fundamental  
> advantage over Web UIs: real-time event notification. AJAX alone  
> does not address IM, stock tickers, and other collaborative  
> applications that require "push" data streaming.
>
> The key goal of AJAX-style applications is to decompose jarring  
> transitions that download an entire new Web page into a series of  
> smaller, more frequent transactions. Developers consider AJAX to be  
> "asynchronous" because data can be updated without interrupting the  
> user. For example, Google Maps dramatically reduces the perceived  
> latency of scrolling a map by only downloading the newly visible  
> tiles and moving the rest.
>
> In the middleware community, however, the formal definition of  
> asynchrony refers to the ability to send a message at any time, in  
> either direction. AJAX provides the upstream direction, but HTTP  
> would appear to make server-initiated transmission impossible.
>
> Fortunately, clever developers have exploited a loophole in HTML to  
> address this. Browsers are designed to display pages incrementally  
> while downloading pages from slow Web sites. Using hidden frames  
> and JavaScript tags, HTTP can be (ab)used to hold open a long-lived  
> response connection, allowing an application to stream data into  
> the browser.
>
> The simplest way to exploit this is to turn the browser into a 21st- 
> century "green screen" dumb terminal. Manuel Kiessling's open- 
> source ARSC (A Really Simple Chat) uses AJAX techniques to send  
> input lines upstream, whereas a modified HTTP server that holds  
> open thousands of simultaneous connections rebroadcasts the chat  
> stream to other users. Another example is KnowNow's SpeedReader  
> product, which is useful for alerting employees to relevant RSS  
> news items.
>
> The subtler and broader implication of combining AJAX with  
> asynchronous event notification is to extend publish-and-subscribe  
> application integration across the Internet. Several open-source  
> platforms provide powerful abstractions for connecting fully  
> interactive Web UIs to enterprise applications and Web services.  
> Nevow (nee Woven LivePage) and Pushlets extend the event loop  
> familiar from model-view-controller GUIs for Python and Java,  
> respectively. Mod_PubSub is designed as an event bus that uses URL  
> path names as topics to implicitly invoke programs written in a  
> wide range of languages. Commercially, KnowNow's LiveServer  
> provides enterprise-class scalability (and even connects to and  
> from Microsoft Excel spreadsheets).
>
> The clear benefits of migrating desktop applications to the Web in  
> terms of maintenance, security, and scalability must be weighed  
> against the costs of slower response times, limited interactivity,  
> and less-than-beautiful graphical interfaces. With AJAX, push  
> technology, and the ubiquitous plug-ins for PDF and Flash, the Web  
> is closer than ever to becoming a viable default platform for  
> application development.

AJAX breathes new life into Web apps

PETER WAYNER, INFOWORLD

26/05/2005 15:20:27

One year ago, Thomas Lackner didn't ask much of JavaScript. When he  
sketched out the architecture to a Web application, he knew he could  
count on the browser language for "set-a-cookie hacks" and for  
loading images, but he turned to the server side for the heavy  
lifting. But when Google began launching highly interactive Web sites  
such as Gmail and Google Suggest, the scales dropped from Lackner's  
eyes and he saw the opportunity.

"It all clicked in my head the middle of 2004," Lackner says. "I  
started trying to add AJAX components to every Web app I worked on."

AJAX is the newly minted acronym encompassing a fresh vision of  
empowered browsers: Asynchronous JavaScript and XML. Before AJAX, Web  
pages displayed links, forms, and buttons. When a user clicked on a  
link or a button, the browser sent a message to a distant server  
asking what to display next. JavaScript would typically be used for  
nothing more than to check form inputs. Web pages were as static as  
pages in a book.

The post-AJAX browser can think on its own without saying "Mother may  
I?" to a distant server. Processing threads running in the background  
preloads page content. If a user clicks on a link or a button, the  
browser can update page content using JavaScript. Google's Gmail, for  
instance, hides or displays parts of an e-mail thread without waiting  
for a response from its server, eliminating network lag. If  
information must go to the server, it too is sent by a background  
process.

Brendan Eich, the creator of JavaScript at Netscape, says the world  
is just now discovering what he imagined back in 1995. He says, "We  
[Marc Andreessen and I] always intended JavaScript to enable client- 
centric apps that did not have to reload pages from a server."

A New Kind of App

AdaptivePath's Jesse James Garrett, who coined the AJAX acronym in an  
essay written in February, says that the response has been  
surprising. "Right now, it's all so new that what we've got is a lot  
of excitement," he says.

The excitement is understandable when you consider the advantages  
AJAX brings. For one thing, it greatly simplifies software  
distribution. Browsers load AJAX applications automatically.  
Customers are often reluctant to install custom applications, but  
most people can be convinced to visit a Web site.

The AJAX approach has several other advantages, as well. JavaScript  
running on the client reduces bandwidth and processing demands on the  
server. Well-designed code that is truly asynchronous also gives the  
server more time to respond to queries, reducing this load even  
further by spreading out peak demands. It even increases security by  
encrypting data on the client side, before it travels across the  
network.

The Basecamp project management application from 37signals is a good  
example of a Web application developed using the new paradigm. Adding  
a new to-do item pops open a window to accept input without a round- 
trip to the server. But when the new item is saved, the browser still  
must wait to ensure that it was stored successfully. JavaScript code  
updates the server in the background while displaying the note,  
"Moving...Just a moment." There is still plenty of interaction with  
the server, but the JavaScript code speeds it by handling many of a  
user's clicks.

David Heinemeier Hansson, a programmer at 37signals, says he's  
concentrating on removing the lag time when a user submits a form.  
"If you have a Weblog and you add a comment, it will be updated on  
the server side in the background. Whenever you need to add or change  
content, you can do it without reloading."

Some of the buzz around AJAX has been generated by Web designers as  
well as programmers. AJAX's flexibility is invigorating for Web  
designers because JavaScript can control any aspect of any images or  
type on a page. Fonts can grow or shrink. Tables can add or lose  
lines. Colors can change. Although none of these capabilities are new  
to programmers accustomed to building client applications -- or, for  
that matter, Java applets -- they are novelties to Web designers who  
would otherwise be forced to rely on Macromedia Flash.

The excitement may signal a newfound synergy between designers and  
programmers, who can now speak the same language about the page.  
Notations from CSS, a language spoken by Web designers, are used  
directly by the JavaScript coders. The result is a Web page that  
behaves with some of the snappiness of a dedicated client application  
-- without any of the headaches of distributing and installing  
software on a client machine.

"For me, it's not about building something big, it's about making  
sure that the experience is right for the right people," says Jason  
Fried, president of 37signals.

Browser Problems Persist

Enthusiasm for these new techniques, however, is usually tempered by  
reality. There are few good tools for AJAX development, the platform  
can be unstable, and adherence to standards is inconsistent. Even the  
biggest proponents complain about differences between Web browsers  
and concede that they don't understand the best way to add many  
interactive features. What's more, these new capabilities can confuse  
users who don't expect the features and, in some cases, can even open  
up new security gaps.

Many AJAX applications require features that are only included in the  
version of JavaScript bundled with newer browsers such as Firefox or  
IE 5.5. Others use functions that work correctly in one version of a  
browser but not another. The XMLHttpRequest object, for instance,  
parses XML from Web services directly, a feature that makes it much  
easier for a programmer to interact with any source of XML. Before  
this feature debuted in IE 5.0, developers could still download  
information from distant Web sites, but they needed to use different  
frames.

Some of the newest browsers offer stable platforms for using XSLT  
(XSL Transformation), but the details seem to be fluid. There are big  
differences in the way IE 5.0, 5.5, and 6.0 handled namespaces.  
Mozilla 1.8 now shares many of the same capabilities, but earlier  
versions don't.

Programmers are forced to smooth over some of these ambiguities by  
building custom loaders that match the code to the browser version.  
Rob Brown, an early AJAX developer and creator of the Firefox plug-in  
Aardvark, is optimistic. "Luckily, most browser differences can be  
fairly easily encapsulated into a few utility functions, and the  
'meat' of your AJAX application can be free from ugly conditional  
code," he says.

But these contortions can be painful, and some are simply abandoning  
earlier browsers. "We're working on a project now called Backpack and  
it's going to be one of the most advanced AJAX apps outside of  
Gmail," Fried says. "We made the decision to just say no to IE 5. It  
was a conscious decision we made. It's about time."

This same challenge faces many enterprise designers. If a Web  
application will only be used internally, an enterprise architect can  
reasonably assume that every browser in the company meets a certain  
specification. Such a uniform infrastructure is much easier for  
programmers. But a company that distributes Web applications to  
customers can't make the same assumptions. There will always be some  
customers running old versions of browsers.

Code Headaches

Dealing with browser ambiguities is just the first challenge.  
Development tools for building JavaScript are still few and often  
have a rough feel to them. Features that programmers of other  
languages take for granted are just now appearing in the JavaScript  
world -- for example, debuggers such as Mozilla's Venkman aren't  
widely used by JavaScript coders accustomed to reloading pages to  
look for errors.

Ed Felten, a professor of computer science at Princeton University,  
cautions that programmers may inadvertently insert security holes  
when translating server-side features into JavaScript code. Although  
JavaScript runs incoming code in a "sandbox" with no API for  
accessing local files, opportunities for mayhem remain because the  
code can still access external Web sites. DDoS attacks, for instance,  
can be easy to code.

What's more, JavaScript code is not compiled the way languages such  
as C and Java are. And end-user can view or even edit the JavaScript  
code before it runs. For example, an attacker could search for  
strings of text containing SQL instructions and replace that code  
with different queries that retrieve different information from the  
server. "Every time a string goes anywhere, you have to think about  
it," Felten says.

The appearance of new glitches such as these requires Web designers  
to think twice about new features. Browser users have come to  
understand the way traditional Web applications work. They have been  
warned many times, for example, that clicking a button twice could  
create a double charge on their credit card. AJAX applications break  
many of those assumptions.

"People are used to clicking a check box and confirming things. Now  
you don't have to. That introduces some confusion," 37signals' Fried  
explains. "Now in some places there's a button and in some places  
there isn't. There are a lot of pitfalls, but they're not  
insurmountable by any means."

What's more, the JavaScript language itself is still evolving.  
Whereas languages such as Java and C++ are highly standardized and  
governed by relatively rigorous committees, JavaScript still feels  
like an experiment at times. There are huge differences between the  
way that IE, Mozilla, and Safari execute some JavaScript code and  
often substantial differences between different editions of the  
browser. The core of the language is a standard known officially as  
ECMAScript, but each browser often handles other features differently.

Will AJAX Prevail?

Despite the cross-platform challenges -- and some developers point  
out that there is little reason for Microsoft to make its browser  
completely compatible with Firefox or Opera -- this new model shows  
promise. AJAX applications can have much if not all of the  
functionality of client-side applications. Many programmers react  
with surprise when they see editors such as Bitflux, FckEditor, or  
Kupu written entirely in JavaScript, but applications such as these  
are likely to become commonplace, and even more features are bound to  
emerge.

Some companies see an opportunity here. Thomas Lackner's development  
group at ModernMethod is rolling some of its development efforts into  
an open source library Lackner calls SAJAX, short for Simple AJAX.  
JackBe, on the other hand, sells a collection of small libraries that  
abstract away many browser incompatibilities. A programmer can add  
Excel-like spreadsheets or forms to a Web page and the JackBe  
libraries will handle much of the interaction with the client.

Which brings us back to the future as the Web finally discovers what  
Eich and the original team at Netscape imagined long ago. When asked  
what held it back, Eich speculates, "It was hampered by  
incompleteness, a rush to standardize, the browser wars killing  
Netscape, and a dependence on Java to do 'real graphics' and 'real  
network input/output.'" Now that JavaScript has matured beyond those  
problems, Eich is enthusiastic to see what comes next.


More information about the FoRK mailing list