A rich client tipping point

Francis Hwang talks about reaching a tipping point in web application development:

If you are writing a new web application, you should make it a rich-client application from the start. Your servers should not generate any HTML. You should do all that work in the browser with a Javascript framework such as Backbone.js or Ember.js, and the server should only talk to the browser via a REST API.

I’m very close to agreeing with this, but I have my own set of caveats.

First of all: mobile. If you’re using an iPhone 4(S), you might not realize that a lot of web browsers on mobile devices are abominably slow. In terms of getting the first page of your app/site up and running on a mobile browser, an HTML page rendered on the server is going to beat a client-side JS application hands down in at least 90% of cases.

After that first page has rendered, the comparison is different. A server-rendered site/app with full-page reloads is (probably) going to have to do more round-tripping, re-parsing and rendering, whereas a client-side app that has bootstrapped itself might only need to load up small chunks of data and refresh parts of the page. But remember that mobile devices are often tight on working memory, and even switching between tabs (let alone switching between apps) can be enough to kick your app out of memory, so that it has to bootstrap again when you switch back.

With IE6 and 7 effectively dead, the desktop doesn’t really have this problem any more. Desktop browsers are now sufficiently fast and capable that the bootstrapping cost is tiny, and from an architectural point of view separating the front-end from the back-end API is the service-oriented way of doing things, which is to say the right way.

(Then we still have to make our client-side apps internally resilient and service-oriented, so that one poorly performing component on the page doesn’t crash the whole app. But. Baby steps.)

It irks me that mobile web development, which in many ways was running ahead of classic desktop web development (advanced CSS3 capabilities, lack of IE6, et al.) is now going to fall behind in this architectural shift. Instead of incapable legacy browsers (IE6,7), we’re stuck with at least a couple of generations of poorly performing devices. The platform that is most suited to “app-like” web content is the one least capable of running the damn things.

Having said that, it’s important to know your audience. In Western Europe, at least, turnover of mobile devices is high, and the shift away from Blackberries and Nokias towards iPhones and Androids is massive. As usual, “it depends.”

Secondly, there’s the small matter of linkability and history management. If there is any part of your application that you want people to jump to directly, either as a bookmark for their own benefit, or as a link to hand out to others, it has to be have a URL. Using hash fragments for navigation may be a well-established pattern, but it’s still a hack. So long as you’re using hash fragments, that URL can only be run on the client. pushState() and replaceState() can fix this, but we’re still a little while away from these methods being universally available (IE10).

  • And then, if I’ve been clicking around in the application, what happens when I press the back button? Does it take me to a previous state within the application, or does it take me out of the application altogether? I don’t think that the field of front-end development has answered this question with a consistent set of patterns to meet (and reset) user expectations yet. Far too often I still hear, “er…don’t use the back button because that’ll break everything”.

    The back button doesn’t reign as supreme as it used to, though; multi-tab browsers have seen to that. Running an app in a dedicated browser tab, and closing it when you’re finished is a common option now. Adding a web app to your phone’s home screen so that it can run without browser chrome is less common, but on the rise. Still, the back button is likely to still be in play in the vast majority of cases. If you’re going to build an app, make sure that you have a plan to deal with it.

    Of course, none of this applies to document-oriented web content. But the distinction between apps and documents is an entirely different discussion.

  • CategoriesUncategorized

    2 Replies to “A rich client tipping point”

    1. Well, that’s why you use native apps on mobile devices. For that reason, and a plethora of others, really 🙂

    2. It is funny that a device that has issues rendering the shit stew that is the web can run the unreal engine at proper framerates. Maybe it is the busted and out of date tech of the web that needs to evolve.

    Comments are closed.