pko.ch

Polyglot hacker & Architect

Native on the browser. Browser on the native. I’m not quite sure.

I 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:

  1. 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.
  2. 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.
  3. 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.

4 Responses to “Native on the browser. Browser on the native. I’m not quite sure.”

  1. João Vale Says:

    One good reason: security. Remember that in a browser it’s way easier to get code running that you didn’t intend to than with a native application, so you probably don’t want to give it too much access to the system. I might be somewhat prejudiced because, well, code is code, but I don’t feel safe knowing that some javascript might be accessing my USB drives. Might be a false sense of security, but I still think that I have more control over what runs on my system natively than over what the browser is doing.

  2. pkoch Says:

    I believe that is a false sense of security. Do you read everything you run? How do you know you haven’t downloaded a misnamed SD card wiper from Android Play?

    Also, it would ask for your permission. Picture something like you have now for geo.

  3. Ricardo Afonso Says:

    On Vale’s behalf, the delta of difficulty between choosing and installing a rogue app from the Store to accessing a website that requests permissions (Yey! Modal dialogs!) is significant.

    Ricardo

  4. pkoch Says:

    Yes. That’s the flip side of the ease of running a web app. As long as the modal dialogs (yay!) keep me safe, I’m fairly ok with it.

Leave a Reply