Hacker News Reader

Comment by zerostar07 | Hacker News Reader

By the same argument, though, apps will be obsoleted as soon as the next battery technology arrives, because, let's face it, installing apps, updating and uninstalling is a ghost long dead. As soon as Apis to access camera, microphone etc come to the browser, who would choose to program native?

View on HN

> installing apps, updating and uninstalling is a ghost long dead.

So, when not installing native apps (which takes time) we add - in the case of e.g. the iphone - webapps (links) to our home screens. Which is faster than installing a native app. After that we 'endure' a longer loading time every time we start the app. And we still have to remove the icon from our home screen when we're done with it.

Mind you, I see the advantages of web apps; but this does not seem like any different from the native app use case; it seems a bit worse to me actually.

> who would choose to program native Performance junkies? graphically intensive app-developers (games?). Sure, we may have an 'opengl'-component to use in our webapps; but why the extra overhead?

Long caching headers can keep your javascript heavy web-app from being downloaded every time - the first time you hit the url it "installs" (by caching the files) and after that it loads in about the same time as a native app.

Very true. I stand corrected.

Only thing left is browser "splash screen"/loading image customization and the experience could be near native.

According to http://developer.apple.com/library/IOs/#documentation/AppleA... you can do this for iOS.

    To add a splash screen during loading, create a 320x460 .png file, and then link to it in the header:

    <link rel="apple-touch-startup-image" href="./startup.png" />

I've actually never tried this.

It's good to know; but the only thing I found (note: it was a quick google session) that comes close to this for Android is when using PhoneGap to build a 'native app'.

Thanks for the info!

Web app icons don't make sense as you 'd soon end up with thousands of them. I imagine future phones will just have a voice-recognition-enabled search box instead of icon grids.

The same could be said about native apps. There are more than enough apps in the various app stores to fill numerous 'springboard screens'. On the other side we only use a small set of apps. Why would habits change when switching from native to web-based when the experience is the same?

It depends on the purpose of the app.

There will still likely be carrier restrictions on bandwidth, and general connectivity issues. Open wifi is far from ubiquitous and many carriers still have poor coverage (AT&T has no usable signal in many parts of my house), not to mention situations like wanting to play a game or use an app while on an airplane.

Some kind of hybrid model may evolve instead. You install an "app" that is little more than a data cache and a skin/UI for the phones browser. In a connected scenario you are using the app in "web app" mode. In a situation when it can't connect, there is enough intelligence to rely on a local data store or something. It doesn't cover all scenarios, but might bridge the gap a little better.

Aside from highly specialized tasks, or those leveraging media/interfaces that web apps don't yet have access to, I'd imagine that's quite possible; not unlike the situation on the desktop today.

I'm just not optimistic about that "next battery technology" arriving any time soon.

There are other ways to spend extra battery power.

If there weren't, 30+ years of Moore's law on the desktop (20 doublings, so let's say a speedup of about 1,000,000) would likely have led to desktop programs written in some scripting language.

Reply on news.ycombinator.com