4 ms·

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 unins

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?

bulte-rs 15y ago
> 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?
- d2vid 15y ago
  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.
  - bulte-rs 15y ago
    Very true. I stand corrected. Only thing left is browser "splash screen"/loading image customization and the experience could be near native.
    - bphogan 15y ago
      According to http://developer.apple.com/library/IOs/#documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html 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.
      - bulte-rs 15y ago
        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!
- zerostar07 15y ago
  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.
  - bulte-rs 15y ago
    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?
roc 15y ago
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.
- Someone 15y ago
  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.
brk 15y ago
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.

bulte-rs 15y ago

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

d2vid 15y ago
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.
- bulte-rs 15y ago
  Very true. I stand corrected. Only thing left is browser "splash screen"/loading image customization and the experience could be near native.
  - bphogan 15y ago
    According to http://developer.apple.com/library/IOs/#documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html 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.
    - bulte-rs 15y ago
      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!
zerostar07 15y ago
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.
- bulte-rs 15y ago
  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?

roc 15y ago

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.

Someone 15y ago
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.

brk 15y ago

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.