When you build a mobile app that uses the network, it is instantly clear that your app needs to be robust against all sorts of network failures:
Dealing with these is hard, but not impossible. Applications retry at various levels trading off battery life and user perceived performance all the time. After enough work, you can make the app functional.
But if you try to write an app using HTML5, how do you do this?
You can’t.
The web simply isn’t designed for partial network failures on a web page. Web pages are comprised of hundreds of subresources from multiple sites these days. What happens when CSS #5 out of 32 resources fails to load? What happens when you can’t connect to i.amazon.com even though you already loaded the main content from www.amazon.com? Does your application even know? Generally not. You can trap for some sorts of errors; but the browser will NOT automatically retry on any of these failures for you. Most likely you’ll be left with a web page which renders incorrectly, hangs forever, or throws javascript errors on the whole page because a critical set of code just never got loaded.
Of course, these problems can happen on your desktop, too. But they generally don’t happen as often. And when they do occur, every user easily becomes his own network administrator thanks to the web browser’s handy dandy “reload” button. How many times have you drummed your fingers for a few seconds before reloading a page? Probably a lot! But on mobile, network errors occur *all* the time. Do mobile apps have ‘reload’ buttons? Generally not – users are becoming quite accustomed to apps which can handle their own errors gracefully.
Sadly, I think this is one more nail in the coffin against HTML5 on mobile. Browsers need to be completely overhauled to properly deal with network errors and retries before HTML5 can be a serious contender to native applications.
You are as it happens condeming the whole of web browsers and the only approach to document based web access we have ever known.
Of course you cant build robust applications in the browser, that handle all errors gracefully. Duh.
I mean this is a limited technology, how about the fact that you cannot even guarantee render order of anything in the browser?
Kind of important if you want to build a stable canvas UI for the user to interact with.
The web is the web. Building applications on it will always be a sacrifice compared to web enabled clients that use different (read BETTER),usable front ends.
The browser makers keep trying to improve the user experience but the basic rendering and network engine is so fundamentally flawed, that it will be a document centric viewer for a long time to come.
And maybe thats not such a bad thing anyway.
Your argument is flawed on multiple accounts:
1) You’re arguing one can’t build a reliable system on top of an unreliable one. This is a flawed assumption because we’re constantly doing that (see for instance tcp/ip which is a reliable system built on top of an unreliable one, datagrams).
2) HTML5 (and it’s related technologies like client side storage, offline web pages, websockets, pushstate, etc.) is specifically inviting you to depart from the “page reload” metaphor, if anything you’re arguing that HTML4 anno 1998 or so is not working well on mobiles.
3) You’re assuming that because your webapp relies on 32 resources, and any of them fails, your app is doomed. Not all resources are created equal, and missing a gradient image isn’t dooming your app. Even a lack of CSS should merely make your app “unpretty”, not unusable.
4) You generally (not just for mobile) try to minimize the amount and size of resources your webapp requires, among other things that means that: you have one CSS file (concat/minify), one JS file (concat/minify), as few images as you can get away with (css gradients, rounded corners, etc.) and if you need images, you use a CSS sprite atlas where applicable. If you’ve done your homework, you can get away with as little as 3 requests, and if you feel fancy, you can inline the JS and CSS so you get away with 1 request.
5) Full page reloads are not required for web apps on mobiles, you can load your app and drive it with JS and XHRs so that the next “view” loaded will do nothing but fire one request that loads a few snippets of text (json, xml, what have you), thereby drastically reducing the likelyhood of failure.
6) Mobile web-apps do have access to the “offline” family of APIs (html5 manifest, localstorage, indexeddb, websql etc.) which allows them to be served up even when no network is available, to detect the network connection status, to store things persistently on the client and to react gracefully to network problems. This is again drastically reducing the impact of network failure, and your WebApp (just like your native app) can react in meaningful ways to it.
You’re definitely thinking like a web head 🙂 (That’s ok!)
I didn’t argue that you can’t build a reliable system on top of an unreliable one. I just said that
a) browsers aren’t reliable without reload.
b) while that mostly works on the desktop, it is a pretty miserable experience on the mobile web
I believe the situation can be vastly improved if we try.
Example: try a web page these days without the stylesheet. Sure, the CSS is optional. Sure, the page still renders. But in my opinion, the resulting page loaded is completely and utterly broken. Users will have no idea how to work with it, and many visual features simply won’t work. Why won’t a web browser retry a CSS automatically? I’ve even seen cases on my desktop where this error occurs and I have to reload the whole thing.
Can we fix it by manually loading the CSS via JS? Sort of. But should we have to?
What if we built a browser that could take care of all this stuff and didn’t need a reload button?
In other words – as the world goes mobile – the browser needs to reconsider its manual network error detection. Instead of relying on the user to press reload, the browser can do a lot more and fix up a lot of these problems for everyone.
Pingback:Community News: Why Speed Is Essential For a Great Web Experience | New Relic blog
Unfortunately, native apps do not necessarily know how to handle network either. That being said, basic UI is probably not going to be affected because unlike web apps, it is packaged with the install.
But for apps that rely on network for content or interaction, networking is still a very important issue and developers generally don’t know how to work with it due to lack of transparency and real testing environments.
I wish there was a better practice around testing UI in real networked environment and people didn’t assume network is infinite and always available.
Good points about connectivity. But why can’t I just build the app in html5 and package it in the app download? That’s still html5 and it effectively get’s rid of networking issues.
@sergey – the point is not that its hard to do. The point is that if you rely on rendering assets downloaded from the web, web browsers have *no way* to deal with partial failures. So, imagine you just have a small bit of your app which you want to render from the web. It sounds great and works on wifi. But take it into the real world and you’ll get sporadic reports of broken pages, empty pages, weird alignments, etc. And its all because web browsers do nothing to account for network failures.
In a native app, do whatever you like.
In a phonegapped app, this is not generally an issue, because all assets are local. But you can’t always make all assets local…
My real question is – is it time for browsers (especially mobile browsers) to figure out how to work without a reload button? If not, why not?
If your building a web “app”, as opposed to a web “site”, its trivial to load your assets through JavaScript instead, in fact you probably already are. It sounds like your primarily talking about mobile websites, not a proper mobile web app, these days, asset management via JS for web apps is pretty common place and normal, so I really am struggling to understand your point here…
Mike – just wait for websockets to infiltrate every technology stack, and every web browser. I believe this will drastically change the face of the internet from “pages” to real time “apps”.