Comment by roc | Hacker News Reader

Comment by roc | Hacker News Reader

Webapps need to better handle offline usage and poor network conditions. Until then, apps still have a huge leg up on mobile devices.

Mobile devices are battery constrained. Radios to provide data feeds are a big factor in battery drain. Interpreted languages increase battery drain. And network coverage is far from universal, to say nothing of download caps and cell network performance concerns.

Apps are preferred today because they're more responsive, they drain less power and they're generally usable offline and in dodgy network conditions. The web has many advantages over native applications, but until it gets better for mobile users, users are not going to get past the more-immediate shortcomings to care much about those advantages.

And given that we seem to have reached a point where potential battery life past 1 day of solid use is traded off for greater performance during operation, I don't see the battery/network situation changing much any time soon.

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?

> 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?

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.

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.

There are advantages and disadvantages to both - web apps are available anywhere you can find an Internet connection and browsers connected to the Internet are in practice more readily available than your device filled with native apps.

I don't know about you, but the same phone travels in my pocket, so those apps are available to me 99% of the time. The available everywhere advantage of the webapp was a big deal because computers were heavy, and that's been diminished.

That said, some sort of standard interoperability between phone and laptop/desktop apps would be nice, and iCloud APIs seem to be a stab at that, but it's probably a pipe dream to hope that that will become universal. So maybe you're right.

A phone is limited in what it allows.

You can certainly read emails on it, however if you want to write emails that are longer than a couple of words, nothing beats the 100 WPM a real keyboard gives you. And most things you do in your daily work are not feasible on a phone.

And sure, my laptop always accompanies me, however there are always emergencies and on my laptop I prefer web interfaces anyway. I haven't used email clients on my laptop ever since I discovered GMail.

What do you find insufficient about Cache Manifest?

Adoption.

You mean appcache? For starters, size restrictions.

it's also a lot easier for developers to make money from native apps (free distribution, no infrastructure needed) vs. web applications (requires a lot of traffic, infrastructure, servers, bandwidth, system administration, etc.).

Reply on news.ycombinator.com