Archives

A reader emailed me this old article from CNN Money discussing the concept of the webtop, i.e. that

A killer app no longer requires hundreds of drones slaving away on
millions of lines of code. Three or four engineers and a steady supply
of Red Bull is all it takes to rapidly turn a midnight brainstorm into
a website so hot it melts the servers.

What has changed is the way today’s Web-based apps can run almost as
seamlessly as programs used on the desktop, with embedded audio, video,
and drag-and-drop ease of use. Behind this Web-desktop fusion are
technologies like Ajax (asynchronous JavaScript and XML), Macromedia’s
Flash, and Ruby on Rails. We’ll spare you the technical details;
suffice it to say that these technologies are giving rise to a new
webtop that may one day replace your suite of desktop applications.

I already hate the term "webtop," though I’ve used it myself in the past. The article goes on to discuss the various webapps that are starting to move into areas once reserved for desktop applications, then lists of a few noteworthy apps, such as 37signals campfire chat client.

The conclusion? We’ll all be doing our word processing over the web from now on.

Now I like a little bit of breathless hype as much as the next guy, but this is over the top. Yes, webapps are going to change, but there are certain limitations to the medium that will make the webtop a much tamer place:

• Reliability and performance – why aren’t most desktop apps in corporate environments served up as client/server apps? The technology is there; the kinks of client/server have mostly been worked out. License sharing could save tons of money. The benefits of reliable, centralized storage and ease of collaboration seem pretty obvious. Yet the most we see is networked storage of documents. The reason? Even on a corporate network, performance and reliability are not high enough to make client/server computing for desktop apps attractive.
• It’s more than just CRUD on speed – even after the widespread introduction of the WIMP (Windows, Icons, Menus, Pointing device) environments in the 80′s, it took a while for programs to mature beyond GUI versions of Lotus 1-2-3. We didn’t see precursors to Photoshop until a few years after the introduction of the Mac. Most webapps today are still glorified CRUD (Create, Read, Update, Delete) engines. Writing the more substantial applications will take a good bit of work, not just a few cans of Red Bull (or Jolt!, sniff).
• Writely ain’t Word – more like Wordpad. If Writely was out as a desktop app, it wouldn’t get a second look. Yes, there is a need for a Word-compatible, easier, less bloated, free word processor, but they never seem to make it. Yes, a web based word processor that saves your work more frequently than an occasional submit is kinda cool. But the truly cool part is the collaboration feature of Writely, and honestly, there are other, better solutions for that.
• Can I Use it Offline? – You’re not going to be online all the time. The moment you have desktop versions that can function independent of the server, is it still Ajax or a Javascript/Browser app with save capability?

This hype around Ajax is really starting to remind me of the first dotcom boom (See FauxJAX for a good sendup of this). I had a few venture capitalists back then asking me to look at business plans that added "the web" to their business models. My rule for evaluating these was always the same: what does the web add? Most times it didn’t change anything; it was just another marketing channel. For others, like online classifieds, it removed distribution costs. For the social networking type businesses, it made it easier and less costly to jumpstart the network effect.

So, for those going gaga over Ajax, ask yourself, what does Ajax add? If you can’t come up with a good answer, odds are it doesn’t add a thing.

I’ll be giving a talk at the Chi2 monthly meeting on Wednesday, April 26, 2006. The highlights are:

• Why web applications are they way they are and how things are changing
• First attempts: frameworks and toolkits that extend current practice
• How Ajax has turned the browser into a desktop
• Component-based GUI’s and how they cut down on Ajax Development time
• Which frameworks get it right

For more information see here. If there is a podcast, we’ll try to make that available along with the presentation.

Most web applications are still request driven, i.e. the browser makes a request and backend state is updated as a response to that request. There is some backend processing, but usually that processing is very losely coupled with the webapp, updating a backend data store.

Many more advanced apps make use of web services, MDB’s, JMS, and other approaches to perform asynchronous processing. The need for asynchronous processing in webapps has been mostly confined to some special cases, requiring extreme scalability or performance. But now with the advent of Ajax, many new webapps are going to have to perform ongoing background processing in order to update front end displays. Some of these processes are going to exceed the time you want an XHR to be open. Or maybe you want to perform some backend processing tightly coupled to the session and UI, rather than loosely tied to the persistent store.

I’ve used open source tools like Mule, ActiveMQ and the like for some of these things. It does make life a bit easier when doing async processing, but moving to these new technologies will involve a bit of a learning curve for most webapp developers. Sorry, guys, the pain isn’t over.

A number of years ago I was part of a team that developed a workflow application for a company to replace a paper based process. The new workflow app was quite a success in testing and training, so we felt fairly optimistic about the rollout. On a Monday we stood in a bullpen area in the company’s Manhattan headquarters and watched the application go live. One woman used the application to fill out a form and then, rather than hitting submit and sending it on its merry workflow way, printed it out and put it in her outbox.

I’m sure most people involved in systems development have experienced this sort of infuriating situation — I’ve seen enough "DO NOT PRINT THIS FORM!!!" messages on the bottoms of pages to know I’m not alone. No matter how much testing and training is done, some people can’t get their heads around a new way of doing things. They remind me of those stories of the industrial age, when new machines were introduced into traditional ways of doing things, often to comical results.

In order to avoid being stuck in the past like this, you have to remember why you do things in the first place and continually question if they are sensible or necessary. I remember when I started designing what now would be called web applications back in 1994 or so. Stateless searching and reporting was easy to do, but the major challenge came in chopping up your application into different "pages", retaining state across several page loads and dealing with the "Back" button, a sort of rogue "Undo" function that didn’t play nice with the application design. You ended up doing lots of kludgy things that you wouldn’t do in a GUI or command line application. You had to think differently in order to build successful web apps.

As I review the various web application frameworks, most of which have the page based concept at their core, I have an uneasy feeling that we’re missing an opportunity to rethink how we build webapps. Isn’t it time to discard the page model and go back to a component model that has been so successful and productive on the desktop? Imagine undo functions that don’t depend on the "Back" button, Browser specific code that is concentrated in a few classes, powerful, rich client applications in a fraction of the code. Let’s rethink and DO NOT PRINT THIS FORM.

I’ve been beating the drum of component based GUI frameworks for Ajax for a while now. To understand why, I think it’s useful to look at the evolution of the desktop GUI framework and understand what makes them so successful. Over at ACM’s Queue publication, I came across an article that gives a nice overview of what an application framework does and the characteristics that make it successful. This following struck me as especially apropos with regard to most of the current Ajax frameworks.

A framework exhibits "inversion of control" at runtime
via callbacks. These callbacks invoke the hook methods of
application-defined components after the occurrence of an event, such as a mouse
click or data arriving on a network connection. When an event occurs, the framework
calls back to a virtual hook method in a preregistered application component,
which then performs application-defined processing in response to the event.
The hook methods in the components decouple the application software from the
reusable framework software, which allows each to change independently as long
as the interface signature and interaction protocols are not modified. Since
frameworks exhibit inversion of control, they can simplify application design
because the framework—rather than the application—runs the event
loop to detect events, demultiplex events to event handlers, and dispatch hook
methods on the handlers that process the events.

Inversion of Control, it’s not just for Spring anymore. Seriously, though, how many of the current Ajax toolkits — I’m not sure that with the exception of appfuse it’s correct to call them application frameworks — give you IoC? I’ll be watching to see if they make the transition to frameworks and will give credit where credit is due.

Paul Browne has nice little survey post over at O’Reilly about Ajax frameworks. All’s cool until I stumble across the following:

Echo2 – Evolution of original Echo Framework, can run in any Servlet container.
Original has cult following, but doubt if it will become the number 1
web framework.

I hear you, Paul. I remember evaluating Echo1 a long while back and thinking to myself: "why would you want to build a web application the way you would a component based desktop GUI? The behavior is so different, the lack of control, layout, look and feel, etc., etc." My conclusion was that Echo1 was a nice design solution applied to the wrong problem.

Fast forward to today. I have DHTML, CSS, Javascript, XHR, etc. I have complete control over what shows up in the browser, anywhere, any time, anyhow. I’ve got people writing thousands of lines of rich client application code, business tier logic leaking into the browser, cat and dogs living together…you get the idea.

Now the Echo design solution makes plenty of sense. The simple report and forms beast of the early 90′s has turned into a kind of GUI desktop. Now my reaction is "why wouldn’t you want to write a rich client web app the way you would write a component based desktop GUI?" It’s a proven design. Nobody twiddles the bits by hand anymore. And when the browser wars start up again, the standards start diverging, and your Ajax apps start breaking, then the problem starts resembling that of a cross platform GUI, i.e. isolating Ajax variations in browser specific peer classes, much like AWT.

You can easily imagine running the same application as a Swing desktop GUI or a browser embedded Flash app. That’s if the design is right and makes use of what? That’s right, browser or rendering layer specific peers.

Guess who has all that today? That’s right, Echo2. Come on and drink the Kool-Aid.