When “MobileMe”:www.me.com launched with a beautiful new design, the web application suite was essentially unusable because of terrible performance. Timeouts and slow page refreshes were the norm. At the time, I didn’t think too much of this. I just waited a couple of weeks until they had either improved their backend infrastructure or until traffic had died down enough to make the site work again.
But one thing that did catch my eye is the insane number of Ajax hits from the SproutCore-based UI. Even “Cappuccino”:cappuccino.org/, which I praise as brilliant to everyone I talk to, seems to join Gmail’s progress bar with this same loading overhead cruft.
Maybe I’m reading too much into it, but I think as work shifts from the server side to JavaScript there is the potential for waste and chattiness. It’s like the countless pixel spacers from the 1990s table-based designs all over again.
Now there’s a counter-argument to this, that you can cut down on the weight of hits by just sending snippets of JSON or some other lightweight format without the baggage of too many HTML tags, but in practice I think the overhead of the large JavaScript libraries and resources to construct modern app-like UIs overshadow potential gains.
Unavoidable? Maybe. Or maybe most applications will still benefit from “traditional” Ajax. “Twitter recently redesigned”:blog.twitter.com/2008/09/c… and made their web site faster in that way. Instead of a completely new client-driven interaction model, they just take pieces of the web site and load content without requiring a full page refresh. Easy wins. Web 3.0 not required.
