Written in July 2004.
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.
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:
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.
Roughly speaking there are two ways of implementing Web applications:
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.
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.
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.
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.
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:
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.