Native on the browser. Browser on the native. I’m not quite sure.
Tuesday, June 19th, 2012I was watching Google I/O 2011: HTML5 versus Android, where two fellows try and contrast why you should do a mobile or/and a native app, and the three main points that stuck with me were:
- Do a proper web app when you’re showing content (or maybe a bit more than that). Proper means responsive. Responsive not only to screen size, but also all other device characteristics or capabilities that enhance the user experience.
- Do native stuff for native stuff. It doesn’t make much sense to build an Android home screen replacement as a web app. No, Active Desktop, you were never good.
- Do native stuff when the current web technologies aren’t quite there yet. Like, accessing the barometer on your mobile. They also talked about being more energy-consumption friendly, integrated with the whole device ecosystem (other apps and whatnot), having stuff on the background (e.g., music players), hard performance demands, et cetera.
This last point doesn’t have to be so. Why don’t we define an “outland”, where browsers are allowed encouraged to expose as much as they can about the underlying software and hardware? We already (sort of) did this with USB and plug-ins. Why not accessing USB devices from the browser? Code is just, well, code. If you can expose it in C, why not invite the javascript engine to the party? And, since HTML has always been about retro-specs, this would also be the perfect segway for weeding out standards.
Tell me one good reason that makes me not want to do this.
PS: However, for me, the web/native choice comes down to:
- If content is king, do a web app. Hands down. You’re bound to have a web site, anyway. You might as well go the not-so-extra mile and make it pleasant for browsers/devices of any creed, belief, or opinion.
- If experience is even more important, I would say to begin by considering a web app (which is always nice for prototyping) but try to draw the line in the sand early. When (and why) are you willing to spend those significant engineering hours to get that extra finesse? Sometimes, it very obvious. You’re not going to wait for WebGL to mature for you to implement a game. You’re going native straight off the bat.