I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Web Applications, promise or hype?

The new buzz word is definitely "Web Applications". Unfortunately, recent publications on this topic are extremely confusing. Web applications require a massive deployment of JavaScript, but everybody skilfully pretends they don't. Besides, I haven't yet found out what Web applications are because no one has bothered to define them.

Are Web Applications here to stay, or are they just another hype?
See Dave Shea's Web Apps are Hot for an overview of recent publications. See also Joel Spolski's perceptive How Microsoft Lost the API War article.

What is a Web Application?

My Web Application adventures started when I became aware of the Web Hypertext Application Technology workgroup (WHAT), largely powered by Ian Hickson of Opera. I like Hickson's Web Forms 2.0 specification, so I took a long and good look at WHAT, too. It focuses on more than Web forms alone, taking the Mozilla/Opera Position Paper as its starting point. In this document Mozilla and Opera present their thoughts on design principles for Web applications.

I asked two questions on the WHAT mailing list, but didn't get any simple answers:

1. What is a Web application? The WHAT homepage defines Web applications as applications on the Web, but that doesn't explain anything.
   It mentions Amazon and eBay as examples of Web applications, but that only confuses me more. Amazon and eBay are Web sites. Sure, you can perform a task there, like searching for items, but should every Web site that allows you to perform a task be proudly declared a Web Application?
   That sounds hypey.
2. The Position Paper gives a long list of extra functionalities that Web applications should support. I immediately saw that, except possibly for clipboard API's, every single functionality can be implemented in JavaScript right now. The Paper admits that scripting is here to stay, but advises to avoid it in favor of "more convenient declarative markup", ignoring the fact that there isn't any available.
   Why do we need to invent a language if we already have one?

For the remainder of this page I will solemnly pretend that there is a definition for "Web applications" that clearly states how they differ from "Web sites", and that we all know exactly what we're talking about (even though I don't).

I do not believe that we need a new language or specification. JavaScript will serve nicely. In addition, I strongly believe that focusing on the technical aspects of Web applications is exactly the wrong thing to do.

A new specification?

Roughly speaking there are two ways of implementing Web applications:

1. JavaScript
2. Any other way

Let's have a look at a noscript solution first. Let's assume WHAT, or a similar initiative, produces a Web Application specification that does not rely on JavaScript.

1. First of all, the specification must be workable. A common failing of all standardizations and specifications is that they pay too much attention to an ideal world and too little to the current state of the Web and the wishes of Web developers.
   Fortunately this specification would not come from W3C, which dramatically increases its chance of being workable. Let's therefore assume that the specification passes this test.
2. Then the specification has to be implemented in Web browsers. This will take quite some time, and even when browsers have implemented the specification they will turn out to be slightly—but nastily—incompatible with each other. The creation and study of even more long, involved and detailed compatibility tables becomes mandatory.
3. Finally—and this is the point many publications blithely ignore—any Web application must be backward compatible, ie. largish browsers that do not implement the specification must still be able to use the Web application—and guess which language we'll need for that minor operation?

We'll have to wait for years before some (but not all) browsers support the specification—up to a point. Then we'll have to understand the specification, find out that it is completely illogical in one crucial respect, work around browser incompatibilities, create a Web application, and when we're finally done we're forced to repeat the entire experience in JavaScript anyway! Meanwhile, our clients will have bought proprietary solutions because they got fed up with waiting somewhere during the third year.

Keep it simple

As you see, JavaScript is inherently superior to any other language for writing Web applications because it is already there.

Conservatively estimated, 90% of the Web users have JavaScript installed and ready for use. There is no need to wait for specifications, you can start creating Web applications right away. The strong and weak points of JavaScript are well known, skilled developers are available, browser incompatibilities have been documented.

Why do people nonetheless search for complicated solutions? Why do they ignore the simple one that is right in front of them? Why don't they keep it simple?

Sometimes I feel that JavaScript's availability is its main weakness. A language that already works everywhere, and that doesn't need herds of objects and classes and APIs and stuff, can't be the right tool for a complex programming job. Besides, using something that is already there doesn't earn you karma points in the programming nirvana. Therefore "serious" programmers are forced to ponderously reinvent the wheel time and again.

Unfortunately for them, any attempt to implement Web applications without JavaScript will result in a terrible waste of time and resources. JavaScript is the only possible solution, since it is the only exisiting solution.

The return of DHTML

However, even if we acknowledge JavaScript's inherent superiority we quickly encounter problems.

Using JavaScript to create Web applications would sharply reverse its newly defined role in modern Web sites. We've just discovered that JavaScript should offer light-weight, simple additions to a page's usability, and that the page should remain accessible when the script doesn't work.

In contrast, Web applications seem to herald the return of DHTML.

In the bad old days DHTML was the cool thing to do. If you didn't have a API for sliding layers you didn't count. A DHTML application was huge to download, buggy in use, and it didn't serve any discernible purpose except stroking the author's ego.

Web applications might cause the same trouble. The underlying desire for complexity is already present, and we only need a few people making gaseous sounds about a "paradigm shift" and "new generation applications" in order to pompously reinvent the DHTML wheel and go through another cycle of expectations and disappointments.

Fortunately we have a chance to avoid this fate, if we change our focus. DHTML focused on technology, on ways to create nifty cross-browser scripts without ever wondering why these scripts were important, or even useful. Right now, the Web application discussion also focuses on technology, and the danger of niftitis looms large, especially since Web applications are supposed to perfectly copy desktop application behavior.

Forget technology. Forget specifications. Forget JavaScript. Forget copying desktop applications.

The real questions

Instead, think about usability and uniqueness. How do Web applications help users in their daily work? What makes Web applications unique when compared to desktop applications that perform the same tasks?

Web applications cannot compete with desktop applications in a desktop environment. Instead, they should capitalize on the advantages of the Web, and on improved usability. Initially usability will deteriorate, since everyone is used to desktop applications and some things work differently on the Web or are just not possible. Which positive points do Web applications have to offset these negative ones?

In order to draw users towards Web applications, they must have clear, easily explained advantages over desktop applications—and not all that stuff about "vendor independence" and "standards support", either. That's tech speak. Users don't care about it.

I feel that a purely technical focus will lead to the slavish copying of desktop application behavior to an alien environment where it'll lose any usability comparision. That's the same error DHTML proponents made years ago. A Web application should be a Web application, not a bad copy of a desktop application.

The following questions need answers:

1. What is a Web application?
2. How does it differ from a Web site?
3. How does it differ from a desktop application?
4. Why would a user want to use a Web application instead of a desktop application? Bear in mind that Web applications will be cruder and simpler than their desktop cousins.
5. Why do we need a new language/specification for Web applications? JavaScript is inherently superior to any new specification because it's already there.

Once these questions are answered, we can start solving the technical questions that implementing Web applications in JavaScript will raise. Conversely, if these questions are not answered Web applications are proven to be yet another hype, and will be dead before the year has ended.

Comments

Comments are closed.