Tag Archives: ajax

Ajax as a scaling tool

When “MobileMe”:http://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”:http://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”:http://blog.twitter.com/2008/09/changes-afoot.html 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.

Essays about the web

Paul Graham thinks “Microsoft and desktop apps are dead”:http://www.paulgraham.com/microsoft.html:

“Gmail also showed how much you could do with web-based software, if you took advantage of what later came to be called ‘Ajax.’ And that was the second cause of Microsoft’s death: everyone can see the desktop is over. It now seems inevitable that applications will live on the web — not just email, but everything, right up to Photoshop. Even Microsoft sees that now.”

He’s definitely off the mark with that statement. Luckily “Martin Pilkington has a counter-rant”:http://pilky.mcubedsw.com/index.php?/site/the_desktop_is_here_to_stay/:

“There seems to be a slightly delusional section of web developers who seem to believe that in a few years time all of our applications and data will be online, while our computers run little more than a browser. Of course this is complete bull.”

As someone who builds both desktop software and web apps, I’m very much interested in what happens in the middle. Next generation Mac software in particular can mix local HTML interfaces, web services, and syncing with a traditional rich UI to build something that is the best of both offline and online worlds.

I had an interesting conversation with “Willie Abrams”:http://willie.tumblr.com/ the other day about why the Flickr UI is better than iPhoto, even if you take away all the social parts of Flickr. The reason is that Flickr introduces extra layouts specific to certain types of activities, such as the excellent calendar view for archives. Another example of a web app UI innovation is the Backpack reminder UI that “John Gruber recently wrote about”:http://daringfireball.net/2007/03/deal_with_it.

Web apps are usually able to iterate on features and interfaces much quicker than desktop software, but that doesn’t make web apps inherently better. Put another way, iCal sucks because it hasn’t been seriously updated in 5 years.

I have other thoughts on this topic, but already I’ve extended this blog post 3 paragraphs more than intended.

Mediocrity is the new application platform

Today marks the 4-year anniversary of this weblog. What better way to celebrate than with a discussion of web applications.

Willie Abrams said in a recent Campfire chat: “Web applications automatically have sync.” He hits on the fundamental principle of web applications popularity, and of course that has always been true. But the difference now is that some web apps are actually fast and usable too. (Gasp!)

The rise of rich web applications that seamlessly mix Flash or Ajax while still staying true to the roots of web architecture (REST design, open standards) has upset the traditional desktop market. I first wrote about this in “To-do lists and embracing the network”, which was in a sense a subtle wake-up call to Mac developers: adapt to the always-on internet or any college drop-out with a shared server will obsolete your app after a few late nights of Rails hacking.

But it frustrates me to see such praise given to web applications that, were they traditional, native apps, they’d be laughed away to obscurity or ignored. Ajax is a huge advancement, but that doesn’t mean that every application works well for the web. I’m sure Google engineers spent an incredible amount of work on Google Pages, but compare it to Apple’s iWeb and it becomes obvious how weak web application interfaces still are.

Luckily some people are working through the really tough problems. Ray Ozzie’s Live Clipboard may be the start of a whole new shift in web app functionality, allowing data to move between web sites and even out of the browser. But true drag-and-drop of structured data between a native app and a web site is still a long way off.

Let’s make some lists, starting with the good.

  • Good web applications are data-driven, multiuser, and use URLs everywhere.
  • There is some key component that is about the browsing experience. That might be sifting through large amounts of data, viewing old logs, finding people.
  • The kind of data requires an adaptable user interface, not something with a strict set of traditional widgets. HTML is perfect for this.

On the other side are web applications that might be built by a team of smart people and with a great technology backend, but the application concepts are confused. They don’t know if they belong in a web browser or on the desktop.

  • Mediocre web applications think that a single web browser window is an entire windowing system with movable child windows.
  • No features that actually have anything to do with the web. The result is that it adds no value to the web as a whole.
  • Trying to replace the whole Microsoft Office suite.

Something else is changing in the HTML/CSS/JavaScript platform. In 2004, Joel Spolsky wrote about how instead of picking Mac, Windows, or Linux APIs, developers are building for the web platform and can deploy to any user’s desktop. Cutting-edge web applications push that claim to its breaking point, as differences between Safari, Mozilla, and Internet Explorer often cause headaches for developers. It’s no surprise when Microsoft’s set of Office Live applications require Internet Explorer, but it is note-worthy when Google’s chat interface does not work in Safari. There is now a whole set of web applications that require the latest version of Mozilla and won’t work in anything less.

Five years ago we accepted that web applications were going to be useful but ultimately unfulfilling, joyless experiences. Now most web apps have risen from bad to simply mediocre. The truly great ones have a foundation and design that would still be unrivaled in a desktop app. These amazing apps are not content to reimplement an old application as a web app just to allow use from any machine, but they take it to the next step: rethink the problem, stay agile, and redesign so that it’s not just web-based, but it’s actually better.