6 ms·

Why Mobile Apps Will Soon be Dead

92 points by Osiris 15y ago

adrianN 15y ago
Can someone explain to me why people think it is reasonable to try turning the browser into a cross platform VM when we already have quite capable and optimized cross platform VMs like Java and .Net/Mono?
- bartonfink 15y ago
  The relative ease of interface design?
- bad_user 15y ago
  Both VMs you mention are too heavy and not real standards.
  - daeken 15y ago
    The Java world is "standardized" (de facto, since it's not a "real" standards board, but still) by the Java Community Process. For .NET, you have ECMA-335 specifying the CLR and ECMA-334 specifying the C# language itself; standards by an internationally recognized body. As for too heavy, I think that's a pretty silly argument, especially considering that Java runs on everything from phones (there's J2ME and Blackberry, plus Android's Dalvik is just an alternative way to look at Java -- register-based rather than stack-based, which speeds up interpretation considerably) to big iron, and .NET runs on everything from microcontrollers (I have a Netduino board sitting next to me) to the 360 to desktops to phones to servers. Heaviness comes from use cases, not intrinsic properties.
    - bad_user 15y ago
      Heaviness comes from use cases, not intrinsic properties. Use cases are precisely the reason Javascript is better for the web. And the current web standards broken as they are, are real standard as in nobody owns them and everybody can improve on top. That's the reason you aren't stuck with IExplorer 6. The Java world is "standardized" (de facto, since it's not a "real" standards board, but still) Windows is a de facto standard too. A standard is meaningless when Oracle threatens with patents the development of alternative implementations. A supposedly standards body is meaningless when the voices and votes of members can't do shit (until Apache Harmony gets access to the TCK, the JCP is basically a lie). .NET, you have ECMA-335 specifying the CLR and ECMA-334 specifying the C# language itself; It's not really .NET, but rather the CLR + C# 2.0. Silverlight, the new stuff from C# 3.0 and onward (Linq, dynamic), haven't been added to ECMA yet and there is no deadline (C# 3.0 released in 2007, 4 years ago). Even the W3C moves faster lately and I'm not holding my breath that Microsoft will ever add anything else to those 2 standards. Java runs on everything from phones ... J2ME is a piece of shit. Android Dalvik is not Java - unless you can also say that .NET is Java (checkout IKVM). Java SE is good for server-side and an all-around good VM, but getting anything usable done for desktop consumers is a frustrating experience at best.
- gruseom 15y ago
  1. Zero-friction deployment. Everyone uses web browsers. 2. Reduced learning curve. Everyone is comfortable with web pages. Compare to the VMs you mention. The JVM failed at #1 despite years' head start and doesn't even try to address #2. A better example is Flash, which threaded the deployment needle amazingly well but still ran aground on the remaining barriers. Mobile is different, though.
- forensic 15y ago
  It's not reasonable. But this is the way the market evolved. The public uses "The Browser" and they expect their apps to be there. They don't want Windows apps and won't pay for them. Basically what happened is Windows sucked and the public figured this out over time. So consumers switched to a new OS called "Internet Explorer" which sucks in a lot of ways but at least it doesn't break their computer while costing them a fortune. "Internet Explorer" also came with a really good online app store, and most of the apps were free to boot. You could just click a "link" and the app would automatically download and run. Hands down a better operating system than Windows.
davidw 15y ago
Desktop apps aren't dead, but I sort of hope things trend this way. I had fun playing with mobile stuff, but... I don't like the idea of rewriting everything 2/3/4 times.
- Hoff 15y ago
  This is the same sort of application churn that was underway before the bulk of the PC market largely settled on MS-DOS and then on Windows, or the morass that was the then-current and then-far-more-fragmented Unix market, which led many vendors to support multiple then-current platforms. With the associated costs. Split your application into its core pieces (written in something reasonably portable, and kept modular where you can) and partition the rest into the platform-specific frameworks and calls, assuming that you can't find an analog to what was once called a "4GL" that meets your requirements and your budget. And from the last time that the third-party 4GL schemes and their sales-critters were prowling the areas I was then working in, it was easy to end up looking at Morton's fork choice. More than a few folks saw their "portable" applications locked into the 4GL frameworks and its continued development plans. Which wasn't a whole lot better than getting tied to the platform, if/when the 4GL vaporized, or raised its rates, or otherwise became less desirable. All common-sense stuff, of course.
toddh 15y ago
Without bindings to hosted mobile functions, like sensor access, etc. you are just making a website. So that's an argument for why mobile apps won't go away.
- revicon 15y ago
  GPS has bindings already, but I agree. Until we can access the camera RAW data and microphone from Javascript, native apps will always be around.
- mcantelon 15y ago
  It seems just a matter of time before APIs for these become part of HTML5.
  - trafficlight 15y ago
    Yep. We already have access to GPS location data in HTML5.
  - JofArnold 15y ago
    Depends if, as a dev, you want to keep waiting for them to become implemented. If I were dreaming of AR, for example, I'd still be waiting.
  - toddh 15y ago
    It's been quite a while. Apple started down that direction, but then the app storm hit and that has been the end of that. And HTML revs much much slower than any phone API, so the native experience will always be superior.
    - loire280 15y ago
      This is a key advantage of native code, but it is being eroded by the rapid development of WebKit and Gecko. Browser makers are driving the environment faster than we initially expected, with the tradeoff of potential fragmentation.
- vailripper 15y ago
yalogin 15y ago
This is exactly why I thought PalmOS had the best app model of all the platforms. Was very surprised to see at the Palm developer event when most of the devs complained about the JS app model.
- orangecat 15y ago
  Was very surprised to see at the Palm developer event when most of the devs complained about the JS app model. I'm not. HTML was fundamentally designed to display static documents. After years of hacks, we've managed to turn it into a somewhat usable application framework, but there's always going to be an impedance mismatch compared to APIs designed for apps from the beginning.
  - swix 15y ago
    This, this is so true. It's a pity, it's like we have come this far with HTML5 and all, but we just can't get the last 100 miles, where.. a webapp can do at the same speed what a native app can. I'm afraid we wont ever get there, not with current implementations / DOM / js, whatever. Which makes me sad.
  - cageface 15y ago
    This is true but in practice it's not so different really. On iOS you layout an xml doc describing your widget tree (maybe via a wysiwyg builder) and attach event handling code to bits of the tree, just like HTML5/DOM. Native apps have better data models but things like Sproutcore might even the score.
jasongullickson 15y ago
(think of the Newton, his first attempt to create an iPhone-like device) FWIW, Jobs didn't create the Newton, he killed it. You don't have to look to hard to know this - http://www.pencomputing.com/frames/newton_obituary.html http://www.pencomputing.com/frames/newton_obituary.html As long as native apps have access to parts of the platform off-limits to web apps there will be a place for them.
- cageface 15y ago
  I agree, although I expect that will be a dwindling proportion of the apps people actually use. All but a small handful of the things I used to do with native apps on my laptop I now do with web apps.
  - jasongullickson 15y ago
    I agree to some extent (the interesting and innovative applications will tend to be native, because they will be using the device in ways unanticipated by the browser vendors). There is another angle to native apps that these articles rarely mention and that is the "channel" created by the app store. For example, many common applications I'm asked to develop for corporate clients can easily be written as HTML5 web apps, and it makes sense to write them this way for cross-platform reason, but all of the clients I've spoken with decide to go the "PhoneGap" route because they want their app to appear in the App Store because this is where there customers are going to be looking for it. There are plenty of practical reasons to host your web app off a wing of your regular website (bypassing App Store approval being the big one) but so many users have become accustom to getting their apps via the App Store that making your app available in an App Store, even if it's HTML5 wrapped in a native-code package, makes sense (at least for now). Of course there is also the monitization issue, but I believe there are some solutions to that already?
adaml_623 15y ago
So really they are describing Mobile Apps that run on the browser rather than directly on the OS. The more things change the more they stay the same.
deleted 15y ago
[deleted]
dstein 15y ago
Mobile apps will die off for the simple reason that it is too expensive for businesses to create and support 6 mobile platforms in addition to their websites. How many businesses are going to pay top dollar for an Android developer to port their IOS app? Dollar for dollar they're better off adding mobile capabilities to their website and support every platform.
swix 15y ago
I highly dislike the fact that native is still more awesome than webapps. It's just not quite there, canvas is slow, webgl is slow to its native counterparts. I mean come on when will this change? Will it ever? Until that day it just feels "meh" to develop "cool" webapps. :( //Disgruntled js developer
king_jester 15y ago
There are many apps that could be just as easily done with current web technologies, so in a sense some of the mobile app space will die. Do I really need a native app for every single website out there that already has a rich web app? As more and more hardware features are exposed through the browser, I think a lot of app programmers will move to web interfaces and technology. That said, there are still several classes of apps that can use the resources provided by native frameworks. Streaming media, high power games, and apps that can be accessed quickly on the local device without network connections all still have a place on the various mobile platforms. Like every new platform, there is an artificially high demand for native apps from developers and hiring companies, but that desire will subside eventually.
joejohnson 15y ago
Markup and javascript are simply too slow to generate crisp, engaging user interfaces. To do that, you need a plugin, which is a)not portable and b) not functionally different from an iOS or Android app. Can you load a web app and its attendant plugins from any old web site? Sure. But by the time you figure out how to monetize the app via some clearinghouse, you've pretty much got the equivalent of an app store, albeit without the clean search and publication tools available to such a store. The bottom line, though, is that the idea of totally portable, script- and markup-driven apps has been a complete failure so far, and is unlikely to change much in the future. Hard coded apps--albeit with increasingly sophisticated porting and distribution tools--are here to stay.
- SoftwareMaven 15y ago
  Hard coded apps--albeit with increasingly sophisticated porting and distribution tools--are here to stay. The last 30 years have shown us computing oscillates between thin clients and heavy clients. I have no reason to believe that will change; we just don't know what the next catalyst will be. I firmly believe it is not Google's web app marketplace (insert joke about app store trademark here ;).
- doublerebel 15y ago
  The slowness is not in the JS and markup itself, but because in the past the rendering engines (browsers) didn't know how to interpret most of the JS calls as defined UI changes. With requestAnimationFrame, CSS animations, and WebGL this is changing -- Browsers are now being told directly which code is UI-specific, so it can be accelerated with hardware and the timing can be synchronized. Translating JS into these more 'native' UI calls across multiple devices and software stacks is already shown as profitable with tools like Appcelerator (iOS, Android, BB, Desktop) and PhoneGap -- which appear native to the average user. Also don't forget that internally the Mozilla suite and many other desktop 'native' apps are built largely with JavaScript, not to mention Palm's WebOS. JS itself is very fast and creating fluid UIs was always possible with a native wrapper (or plugin, as you mention) but now that the tech is making its way into the average browser we will be seeing more and more 'crisp' interfaces on 'average' websites. 'Hard coded' apps will always have their place, but look out: many portable, JS-driven apps are very successful, and are already changing the future. Many people who just think of JS as browser script are being left behind.
bartl 15y ago
The reason why app developers will only reluctantly leave apps behind in favor of web apps, is because of the money. It's very easy to moneytize apps, it comes with the territory; but for web apps? People are used to "free" for web apps, and no wishful thinking can change that.
- bad_user 15y ago
  People get used to whatever you ask them for. I've got 5 active subscriptions to online services, and barrier to entry is indeed higher, but that's only because the competition is tougher (you can't really sell fart apps on the web, but to me that's a feature) - just wait another 2 years and the iTunes store will be filled with freemium.
- gte910h 15y ago
  I honestly think people would happily pay for web apps/games/etc too....if they felt they could depend on them not going away, and payment systems were as easy as they are for phone apps. I think you can't overlook the ease given by unified payments from a trustworthy source that Apple et al brings to the table.
ryannielsen 15y ago
What's the interest in the "Web vs. Mobile App" fight? Both sides are converging towards each other. Hell, look at Google itself – they're sponsoring both Android and Chrome OS and both teams are adding features "claimed" by the other. Solve the problems faced by your users, using the technologies that best amplify your expertise and meet their needs. Period. In the end, almost all users won't give a damn whether they're using a web or native app – they just want something that works well.
- 555imon 15y ago
  Fully agree. Question is on what distribution channel will be used for web apps. Will it be in the browser or applications including a WebView? Users seem to like/get used to the concept of stores as distribution channel for web apps.
- cageface 15y ago
  As a developer you have to place your bets. Developing expertise and a workable codebase takes time on either platform. Unless you have resources to burn you have to pick a side.
ignifero 15y ago
Amen to that. I wonder how long we have to wait for the w3c to create APIs for all sorts of device capabilities, like camera, compass etc. Open standards FTW.
- peter123 15y ago
  The standards for access to device capabilities are already defined. Just waiting for platforms/browsers to adopt them.
ChuckMcM 15y ago
I think its a silly piece, and not really a cogent argument. The author claims 'mobile' apps will be supplanted by 'web' apps (presumably running in a browser which is running on a mobile device). The reasoning breaks down into three claims; 1) There are many more web users than there are mobile users (author claims 2 Billion vs 50 Million) 2) There are some browser apps (Angry birds and NY Times cited) which give you 'offline' access. 3)The HTML5 in the browser will become a unifying API to local functions which will ease development. So lets take these claims one by one and see how they hold up. Market Size - ok there are a lot more web browsers than mobile users. And yet if you look at growth rates (especially if you count 'tablets') the number of users with 'mobile' capability is growing faster than pure web browser seats. If you look at user capability the 'mobile' user may want to do things like 'check in' (location based) or navigate which the generic browser user doesn't do. Finally if you consider the underlying UX tools its just as painful to make an App which works well on 1920 x 1080 screen with mouse/keyboard as it does on an 800 x 400 screen with just touch points. Browser Apps with offline access - This moves the browser closer to hosting the 'OS experience' of the device away from the underlying OS. Google would love to do that since they would realize Sun Microsystem's dream of being able to ship a browser which was the OS can cut out the OS provider (either Microsoft or Apple in this case). However adding this layer not only impacts performance, it also impacts compability since browsers with the same name and version work differently from platform to platform. Not so with mobile apps. HTML5 will develop access to native APIs - I read this, and I imagine all of the zero day exploits that will come of it, if it comes to pass. You take two engineering teams in two separate companies, one providing an OS API and the other providing access to it, and you get Flash all over again. Both development teams come from the problem from different directions and create unexpected problems for the other. Bottom line for me is that I'm not convinced the browser can kill anything except other browsers. That being said, I also think there are big opportunities in mobile / tablet device space for innovations in the operating system, the UX frameworks, and the distribution mechanisms. Disclaimer though is that I was one of the Java guys and I had completely bought into the notion of 'write once, run anywhere'. Making that true turned out to be impossible for a number of reasons, not the least of which that the underlying OS providers were hostile to the idea. So creating an HTML5 uber-alles experience for developing apps seems optimistic to me.
- 15y ago
JofArnold 15y ago
There's several billion radio listeners. And yet for some reason Amazon and Apple have billions of MP3 downloads. The article confuses the tech with the marketplace. Not the same thing.
kin 15y ago
i'm pretty sure you can't replace something graphically intensive as Unreal's Infinity Blade with a cross-mobile-browser web app.
- czhiddy 15y ago
  I think the proponents of web apps only consider the twitter/facebook/etc type of apps in these arguments. If the types of game you're interested in are relatively simple affairs (Angry Birds/Cut the Rope/etc), sure, you could probably make it performant with HTML5. Good luck doing anything more complex (Unreal, PhotoSynth, GarageBand, etc) with javascript without at least 3-4 generations of hardware improvement.
k7d 15y ago
This reminds me "Shortchanging Your Business with User-Hostile Platforms" http://news.ycombinator.com/item?id=2108294 http://news.ycombinator.com/item?id=2108294 It's about drawbacks of using Adobe AIR as kind of a cross-platform shortcut for building apps. From such perspective HTML is really not that different. If you want to deliver the best possible user experience, native apps is the only option in a lot of cases. In a way that is good news for developers since it creates niches.
roc 15y ago
It's always seemed to me that the shift away from native desktop apps had a lot more to do with Windows headaches, rather than any inherent consumer preference for web apps. And for the average user, today's mobile platforms don't have much at all in common with the Windows software life cycle [1]. So I'm not sure why it would be in the users' interests to move to web apps. And thus I'm puzzled at why people expect it to spontaneously happen. Particularly when evidence seems to suggest the exact opposite, people moving toward native apps, on console-like devices. [1] finding, vetting, scanning, installing, using, moving to new machine, syncing, fiddling, repairing, upgrading, cursing, uninstalling.
DrCatbox 15y ago
I remember 20 years ago when File > Save page as... > html archive would make me a very nice web app on the fly. App is the latest craze that has replaced the cloud, suddenly even the direct opposite of an app, the web, becomes an app. Strange. Didnt people know that you could save a web page and access it when you are offline before starting to call it a web app?
checker 15y ago
Why is it one or the other? Can't they just be different views for the same model (assuming the app doesn't need access to lower-level functionality)?
haseman 15y ago
I think I've read this exact article dozens of times since almost since I began writing mobile applications in 2003. The message is always the same 'Web Apps are Coming! They're going to take over! Steve Jobs thought so!' In reality, we'll probably see something that's half-way between a web-app and a mobile app. In the meantime, can we stop predicting the doom of mobile software and get on with fixing what's broken about it?
MarkMc 15y ago
The Roman empire analogy is upside down - the 'web apps' are the Romans, and the 'native apps' are the Visigoths. Three years ago the momentum was with web apps - nobody was developing new 'native' apps. That has all changed. Even websites whose content is perfect for a browser (eg. newspaper and magazine websites, real-estate listings, train timetables, etc) are producing native app versions of their product. How does the author explain that?

92 points by Osiris 15y ago

Can someone explain to me why people think it is reasonable to try turning the browser into a cross platform VM when we already have quite capable and optimized cross platform VMs like Java and .Net/Mono?

bartonfink 15y ago
The relative ease of interface design?
bad_user 15y ago
Both VMs you mention are too heavy and not real standards.
- daeken 15y ago
  The Java world is "standardized" (de facto, since it's not a "real" standards board, but still) by the Java Community Process. For .NET, you have ECMA-335 specifying the CLR and ECMA-334 specifying the C# language itself; standards by an internationally recognized body. As for too heavy, I think that's a pretty silly argument, especially considering that Java runs on everything from phones (there's J2ME and Blackberry, plus Android's Dalvik is just an alternative way to look at Java -- register-based rather than stack-based, which speeds up interpretation considerably) to big iron, and .NET runs on everything from microcontrollers (I have a Netduino board sitting next to me) to the 360 to desktops to phones to servers. Heaviness comes from use cases, not intrinsic properties.
  - bad_user 15y ago
    Heaviness comes from use cases, not intrinsic properties. Use cases are precisely the reason Javascript is better for the web. And the current web standards broken as they are, are real standard as in nobody owns them and everybody can improve on top. That's the reason you aren't stuck with IExplorer 6. The Java world is "standardized" (de facto, since it's not a "real" standards board, but still) Windows is a de facto standard too. A standard is meaningless when Oracle threatens with patents the development of alternative implementations. A supposedly standards body is meaningless when the voices and votes of members can't do shit (until Apache Harmony gets access to the TCK, the JCP is basically a lie). .NET, you have ECMA-335 specifying the CLR and ECMA-334 specifying the C# language itself; It's not really .NET, but rather the CLR + C# 2.0. Silverlight, the new stuff from C# 3.0 and onward (Linq, dynamic), haven't been added to ECMA yet and there is no deadline (C# 3.0 released in 2007, 4 years ago). Even the W3C moves faster lately and I'm not holding my breath that Microsoft will ever add anything else to those 2 standards. Java runs on everything from phones ... J2ME is a piece of shit. Android Dalvik is not Java - unless you can also say that .NET is Java (checkout IKVM). Java SE is good for server-side and an all-around good VM, but getting anything usable done for desktop consumers is a frustrating experience at best.
gruseom 15y ago
1. Zero-friction deployment. Everyone uses web browsers. 2. Reduced learning curve. Everyone is comfortable with web pages. Compare to the VMs you mention. The JVM failed at #1 despite years' head start and doesn't even try to address #2. A better example is Flash, which threaded the deployment needle amazingly well but still ran aground on the remaining barriers. Mobile is different, though.
forensic 15y ago
It's not reasonable. But this is the way the market evolved. The public uses "The Browser" and they expect their apps to be there. They don't want Windows apps and won't pay for them. Basically what happened is Windows sucked and the public figured this out over time. So consumers switched to a new OS called "Internet Explorer" which sucks in a lot of ways but at least it doesn't break their computer while costing them a fortune. "Internet Explorer" also came with a really good online app store, and most of the apps were free to boot. You could just click a "link" and the app would automatically download and run. Hands down a better operating system than Windows.

davidw 15y ago

Desktop apps aren't dead, but I sort of hope things trend this way. I had fun playing with mobile stuff, but... I don't like the idea of rewriting everything 2/3/4 times.

Hoff 15y ago
This is the same sort of application churn that was underway before the bulk of the PC market largely settled on MS-DOS and then on Windows, or the morass that was the then-current and then-far-more-fragmented Unix market, which led many vendors to support multiple then-current platforms. With the associated costs. Split your application into its core pieces (written in something reasonably portable, and kept modular where you can) and partition the rest into the platform-specific frameworks and calls, assuming that you can't find an analog to what was once called a "4GL" that meets your requirements and your budget. And from the last time that the third-party 4GL schemes and their sales-critters were prowling the areas I was then working in, it was easy to end up looking at Morton's fork choice. More than a few folks saw their "portable" applications locked into the 4GL frameworks and its continued development plans. Which wasn't a whole lot better than getting tied to the platform, if/when the 4GL vaporized, or raised its rates, or otherwise became less desirable. All common-sense stuff, of course.

toddh 15y ago

Without bindings to hosted mobile functions, like sensor access, etc. you are just making a website. So that's an argument for why mobile apps won't go away.

revicon 15y ago
GPS has bindings already, but I agree. Until we can access the camera RAW data and microphone from Javascript, native apps will always be around.
mcantelon 15y ago
It seems just a matter of time before APIs for these become part of HTML5.
- trafficlight 15y ago
  Yep. We already have access to GPS location data in HTML5.
- JofArnold 15y ago
  Depends if, as a dev, you want to keep waiting for them to become implemented. If I were dreaming of AR, for example, I'd still be waiting.
- toddh 15y ago
  It's been quite a while. Apple started down that direction, but then the app storm hit and that has been the end of that. And HTML revs much much slower than any phone API, so the native experience will always be superior.
  - loire280 15y ago
    This is a key advantage of native code, but it is being eroded by the rapid development of WebKit and Gecko. Browser makers are driving the environment faster than we initially expected, with the tradeoff of potential fragmentation.
vailripper 15y ago

yalogin 15y ago

This is exactly why I thought PalmOS had the best app model of all the platforms. Was very surprised to see at the Palm developer event when most of the devs complained about the JS app model.

orangecat 15y ago
Was very surprised to see at the Palm developer event when most of the devs complained about the JS app model. I'm not. HTML was fundamentally designed to display static documents. After years of hacks, we've managed to turn it into a somewhat usable application framework, but there's always going to be an impedance mismatch compared to APIs designed for apps from the beginning.
- swix 15y ago
  This, this is so true. It's a pity, it's like we have come this far with HTML5 and all, but we just can't get the last 100 miles, where.. a webapp can do at the same speed what a native app can. I'm afraid we wont ever get there, not with current implementations / DOM / js, whatever. Which makes me sad.
- cageface 15y ago
  This is true but in practice it's not so different really. On iOS you layout an xml doc describing your widget tree (maybe via a wysiwyg builder) and attach event handling code to bits of the tree, just like HTML5/DOM. Native apps have better data models but things like Sproutcore might even the score.

jasongullickson 15y ago

(think of the Newton, his first attempt to create an iPhone-like device) FWIW, Jobs didn't create the Newton, he killed it. You don't have to look to hard to know this - http://www.pencomputing.com/frames/newton_obituary.html http://www.pencomputing.com/frames/newton_obituary.html As long as native apps have access to parts of the platform off-limits to web apps there will be a place for them.

cageface 15y ago
I agree, although I expect that will be a dwindling proportion of the apps people actually use. All but a small handful of the things I used to do with native apps on my laptop I now do with web apps.
- jasongullickson 15y ago
  I agree to some extent (the interesting and innovative applications will tend to be native, because they will be using the device in ways unanticipated by the browser vendors). There is another angle to native apps that these articles rarely mention and that is the "channel" created by the app store. For example, many common applications I'm asked to develop for corporate clients can easily be written as HTML5 web apps, and it makes sense to write them this way for cross-platform reason, but all of the clients I've spoken with decide to go the "PhoneGap" route because they want their app to appear in the App Store because this is where there customers are going to be looking for it. There are plenty of practical reasons to host your web app off a wing of your regular website (bypassing App Store approval being the big one) but so many users have become accustom to getting their apps via the App Store that making your app available in an App Store, even if it's HTML5 wrapped in a native-code package, makes sense (at least for now). Of course there is also the monitization issue, but I believe there are some solutions to that already?

adaml_623 15y ago

So really they are describing Mobile Apps that run on the browser rather than directly on the OS. The more things change the more they stay the same.

deleted 15y ago

[deleted]

dstein 15y ago

Mobile apps will die off for the simple reason that it is too expensive for businesses to create and support 6 mobile platforms in addition to their websites. How many businesses are going to pay top dollar for an Android developer to port their IOS app? Dollar for dollar they're better off adding mobile capabilities to their website and support every platform.

swix 15y ago

I highly dislike the fact that native is still more awesome than webapps. It's just not quite there, canvas is slow, webgl is slow to its native counterparts. I mean come on when will this change? Will it ever? Until that day it just feels "meh" to develop "cool" webapps. :( //Disgruntled js developer

king_jester 15y ago

There are many apps that could be just as easily done with current web technologies, so in a sense some of the mobile app space will die. Do I really need a native app for every single website out there that already has a rich web app? As more and more hardware features are exposed through the browser, I think a lot of app programmers will move to web interfaces and technology. That said, there are still several classes of apps that can use the resources provided by native frameworks. Streaming media, high power games, and apps that can be accessed quickly on the local device without network connections all still have a place on the various mobile platforms. Like every new platform, there is an artificially high demand for native apps from developers and hiring companies, but that desire will subside eventually.

joejohnson 15y ago

Markup and javascript are simply too slow to generate crisp, engaging user interfaces. To do that, you need a plugin, which is a)not portable and b) not functionally different from an iOS or Android app. Can you load a web app and its attendant plugins from any old web site? Sure. But by the time you figure out how to monetize the app via some clearinghouse, you've pretty much got the equivalent of an app store, albeit without the clean search and publication tools available to such a store. The bottom line, though, is that the idea of totally portable, script- and markup-driven apps has been a complete failure so far, and is unlikely to change much in the future. Hard coded apps--albeit with increasingly sophisticated porting and distribution tools--are here to stay.

SoftwareMaven 15y ago
Hard coded apps--albeit with increasingly sophisticated porting and distribution tools--are here to stay. The last 30 years have shown us computing oscillates between thin clients and heavy clients. I have no reason to believe that will change; we just don't know what the next catalyst will be. I firmly believe it is not Google's web app marketplace (insert joke about app store trademark here ;).
doublerebel 15y ago
The slowness is not in the JS and markup itself, but because in the past the rendering engines (browsers) didn't know how to interpret most of the JS calls as defined UI changes. With requestAnimationFrame, CSS animations, and WebGL this is changing -- Browsers are now being told directly which code is UI-specific, so it can be accelerated with hardware and the timing can be synchronized. Translating JS into these more 'native' UI calls across multiple devices and software stacks is already shown as profitable with tools like Appcelerator (iOS, Android, BB, Desktop) and PhoneGap -- which appear native to the average user. Also don't forget that internally the Mozilla suite and many other desktop 'native' apps are built largely with JavaScript, not to mention Palm's WebOS. JS itself is very fast and creating fluid UIs was always possible with a native wrapper (or plugin, as you mention) but now that the tech is making its way into the average browser we will be seeing more and more 'crisp' interfaces on 'average' websites. 'Hard coded' apps will always have their place, but look out: many portable, JS-driven apps are very successful, and are already changing the future. Many people who just think of JS as browser script are being left behind.

bartl 15y ago

The reason why app developers will only reluctantly leave apps behind in favor of web apps, is because of the money. It's very easy to moneytize apps, it comes with the territory; but for web apps? People are used to "free" for web apps, and no wishful thinking can change that.

bad_user 15y ago
People get used to whatever you ask them for. I've got 5 active subscriptions to online services, and barrier to entry is indeed higher, but that's only because the competition is tougher (you can't really sell fart apps on the web, but to me that's a feature) - just wait another 2 years and the iTunes store will be filled with freemium.
gte910h 15y ago
I honestly think people would happily pay for web apps/games/etc too....if they felt they could depend on them not going away, and payment systems were as easy as they are for phone apps. I think you can't overlook the ease given by unified payments from a trustworthy source that Apple et al brings to the table.

ryannielsen 15y ago

What's the interest in the "Web vs. Mobile App" fight? Both sides are converging towards each other. Hell, look at Google itself – they're sponsoring both Android and Chrome OS and both teams are adding features "claimed" by the other. Solve the problems faced by your users, using the technologies that best amplify your expertise and meet their needs. Period. In the end, almost all users won't give a damn whether they're using a web or native app – they just want something that works well.

555imon 15y ago
Fully agree. Question is on what distribution channel will be used for web apps. Will it be in the browser or applications including a WebView? Users seem to like/get used to the concept of stores as distribution channel for web apps.
cageface 15y ago
As a developer you have to place your bets. Developing expertise and a workable codebase takes time on either platform. Unless you have resources to burn you have to pick a side.

ignifero 15y ago

Amen to that. I wonder how long we have to wait for the w3c to create APIs for all sorts of device capabilities, like camera, compass etc. Open standards FTW.

peter123 15y ago
The standards for access to device capabilities are already defined. Just waiting for platforms/browsers to adopt them.

ChuckMcM 15y ago

I think its a silly piece, and not really a cogent argument. The author claims 'mobile' apps will be supplanted by 'web' apps (presumably running in a browser which is running on a mobile device). The reasoning breaks down into three claims; 1) There are many more web users than there are mobile users (author claims 2 Billion vs 50 Million) 2) There are some browser apps (Angry birds and NY Times cited) which give you 'offline' access. 3)The HTML5 in the browser will become a unifying API to local functions which will ease development. So lets take these claims one by one and see how they hold up. Market Size - ok there are a lot more web browsers than mobile users. And yet if you look at growth rates (especially if you count 'tablets') the number of users with 'mobile' capability is growing faster than pure web browser seats. If you look at user capability the 'mobile' user may want to do things like 'check in' (location based) or navigate which the generic browser user doesn't do. Finally if you consider the underlying UX tools its just as painful to make an App which works well on 1920 x 1080 screen with mouse/keyboard as it does on an 800 x 400 screen with just touch points. Browser Apps with offline access - This moves the browser closer to hosting the 'OS experience' of the device away from the underlying OS. Google would love to do that since they would realize Sun Microsystem's dream of being able to ship a browser which was the OS can cut out the OS provider (either Microsoft or Apple in this case). However adding this layer not only impacts performance, it also impacts compability since browsers with the same name and version work differently from platform to platform. Not so with mobile apps. HTML5 will develop access to native APIs - I read this, and I imagine all of the zero day exploits that will come of it, if it comes to pass. You take two engineering teams in two separate companies, one providing an OS API and the other providing access to it, and you get Flash all over again. Both development teams come from the problem from different directions and create unexpected problems for the other. Bottom line for me is that I'm not convinced the browser can kill anything except other browsers. That being said, I also think there are big opportunities in mobile / tablet device space for innovations in the operating system, the UX frameworks, and the distribution mechanisms. Disclaimer though is that I was one of the Java guys and I had completely bought into the notion of 'write once, run anywhere'. Making that true turned out to be impossible for a number of reasons, not the least of which that the underlying OS providers were hostile to the idea. So creating an HTML5 uber-alles experience for developing apps seems optimistic to me.

15y ago

JofArnold 15y ago

There's several billion radio listeners. And yet for some reason Amazon and Apple have billions of MP3 downloads. The article confuses the tech with the marketplace. Not the same thing.

kin 15y ago

i'm pretty sure you can't replace something graphically intensive as Unreal's Infinity Blade with a cross-mobile-browser web app.

czhiddy 15y ago
I think the proponents of web apps only consider the twitter/facebook/etc type of apps in these arguments. If the types of game you're interested in are relatively simple affairs (Angry Birds/Cut the Rope/etc), sure, you could probably make it performant with HTML5. Good luck doing anything more complex (Unreal, PhotoSynth, GarageBand, etc) with javascript without at least 3-4 generations of hardware improvement.

k7d 15y ago

This reminds me "Shortchanging Your Business with User-Hostile Platforms" http://news.ycombinator.com/item?id=2108294 http://news.ycombinator.com/item?id=2108294 It's about drawbacks of using Adobe AIR as kind of a cross-platform shortcut for building apps. From such perspective HTML is really not that different. If you want to deliver the best possible user experience, native apps is the only option in a lot of cases. In a way that is good news for developers since it creates niches.

roc 15y ago

It's always seemed to me that the shift away from native desktop apps had a lot more to do with Windows headaches, rather than any inherent consumer preference for web apps. And for the average user, today's mobile platforms don't have much at all in common with the Windows software life cycle [1]. So I'm not sure why it would be in the users' interests to move to web apps. And thus I'm puzzled at why people expect it to spontaneously happen. Particularly when evidence seems to suggest the exact opposite, people moving toward native apps, on console-like devices. [1] finding, vetting, scanning, installing, using, moving to new machine, syncing, fiddling, repairing, upgrading, cursing, uninstalling.

DrCatbox 15y ago

I remember 20 years ago when File > Save page as... > html archive would make me a very nice web app on the fly. App is the latest craze that has replaced the cloud, suddenly even the direct opposite of an app, the web, becomes an app. Strange. Didnt people know that you could save a web page and access it when you are offline before starting to call it a web app?

checker 15y ago

Why is it one or the other? Can't they just be different views for the same model (assuming the app doesn't need access to lower-level functionality)?

haseman 15y ago

I think I've read this exact article dozens of times since almost since I began writing mobile applications in 2003. The message is always the same 'Web Apps are Coming! They're going to take over! Steve Jobs thought so!' In reality, we'll probably see something that's half-way between a web-app and a mobile app. In the meantime, can we stop predicting the doom of mobile software and get on with fixing what's broken about it?

MarkMc 15y ago

The Roman empire analogy is upside down - the 'web apps' are the Romans, and the 'native apps' are the Visigoths. Three years ago the momentum was with web apps - nobody was developing new 'native' apps. That has all changed. Even websites whose content is perfect for a browser (eg. newspaper and magazine websites, real-estate listings, train timetables, etc) are producing native app versions of their product. How does the author explain that?