Why Mobile Apps Will Soon be Dead(technologyreview.com)
technologyreview.com
Why Mobile Apps Will Soon be Dead
http://www.technologyreview.com/blog/mimssbits/26778
66 comments
"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."
The company I work for uses Java and targets Windows, AIX, HP-UX, AS/400, and Linux. We have remarkably few portability problems with our Java code. It all "just works", as advertised.
I'd be curious to know where all your Java portability problems stem from. The UI (Swing)?
In any case, I do share some concern and skepticism that web apps will rule the roost. At least one company, Microsoft, would seem motivated to make sure web apps cannot completely replace desktop apps, and thus will always subtly cripple IE, the dominant web browser.
The company I work for uses Java and targets Windows, AIX, HP-UX, AS/400, and Linux. We have remarkably few portability problems with our Java code. It all "just works", as advertised.
I'd be curious to know where all your Java portability problems stem from. The UI (Swing)?
In any case, I do share some concern and skepticism that web apps will rule the roost. At least one company, Microsoft, would seem motivated to make sure web apps cannot completely replace desktop apps, and thus will always subtly cripple IE, the dominant web browser.
So if you run a Java program, under the JRE-xx you will get the maximum possible portability. I was the Director of Systems at FreeGate (an internet Appliance company) and we decided to do our 'UI' in Java, in the browser. (feeling it would give us wide reach) but at that time in particular (1996 - 2000) there was a lot of churn in the browser market and point releases of the browser could change significant behaviors.
Today that is less of an issue as pretty much everyone has punted on supplying their own version of Java for the browser and instead relying on the Snoracle version. However the UI compatibility is tied up inside the support for CSS and/or HTMLx where x is 4, 4.1, or 5 even.
Mobile apps for say Android which use their toolkit, and written in Java of course, are reasonably compatible across Android devices. However challenges with Honeycomb seem to have highlighted what happens when you change around some base assumptions. Even the migration from Android 1.6 and 2.0 was fraught with issues around new capabilities (and diverse capabilities) between handsets.
Configuration Management is a Hard Problem (tm) on any system and people see the Windows eco-system or the MacOS eco-system and feel like they should be able to do that cross-platform. I agree that if that problem gets solved in a meaningful way it will forever change the way we interact with our machines, but I don't think browsers are the great hope for cross platform compatibility.
Today that is less of an issue as pretty much everyone has punted on supplying their own version of Java for the browser and instead relying on the Snoracle version. However the UI compatibility is tied up inside the support for CSS and/or HTMLx where x is 4, 4.1, or 5 even.
Mobile apps for say Android which use their toolkit, and written in Java of course, are reasonably compatible across Android devices. However challenges with Honeycomb seem to have highlighted what happens when you change around some base assumptions. Even the migration from Android 1.6 and 2.0 was fraught with issues around new capabilities (and diverse capabilities) between handsets.
Configuration Management is a Hard Problem (tm) on any system and people see the Windows eco-system or the MacOS eco-system and feel like they should be able to do that cross-platform. I agree that if that problem gets solved in a meaningful way it will forever change the way we interact with our machines, but I don't think browsers are the great hope for cross platform compatibility.
@ChuckMcM - "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."
"Configuration Management is a Hard Problem (tm) on any system and people see the Windows eco-system or the MacOS eco-system and feel like they should be able to do that cross-platform."
---
I'll just pipe in here real quick as cross-platform Java apps are core to the open source / middleware product I'm releasing called TyphonRT this summer. It's something I've personally worked on for many years well before Android's emergence. Fragmentation is difficult to solve alone across the variety of OS and device differentiation in the Android ecosystem without even considering cross-platform compatibility with the J2SE.
TyphonRT is one such effort though and is built with a scalable configuration system via a component architecture. Major engineering of the client SDK / runtime will hopefully wrap up by the end of June with a closed beta for those interested w/ public launch end of summer / Q3.
To support distribution across the Android ecosystem and desktop configurations part of TyphonRT is a PaaS system such as when a TyphonRT app is installed it will download any OS or device specific modifications / alternate components to "patch" or provide a stable middleware layer in attempt to keep that write once / run anywhere promise or get as close as possible.
Of note I'll also be dumping over 10 years of solid Java real time app / game dev knowledge too through an expanding tutorial series w/ lots of code examples styled in a similar manner to Khan Academy.
http://www.typhonrt.org/
Ok not to hijack this thread, but the work I am doing as an indie / startup is relevant to this discussion. This kind of solution with the current landscape surrounding Java is only going to come from the open source / indie area.
"Configuration Management is a Hard Problem (tm) on any system and people see the Windows eco-system or the MacOS eco-system and feel like they should be able to do that cross-platform."
---
I'll just pipe in here real quick as cross-platform Java apps are core to the open source / middleware product I'm releasing called TyphonRT this summer. It's something I've personally worked on for many years well before Android's emergence. Fragmentation is difficult to solve alone across the variety of OS and device differentiation in the Android ecosystem without even considering cross-platform compatibility with the J2SE.
TyphonRT is one such effort though and is built with a scalable configuration system via a component architecture. Major engineering of the client SDK / runtime will hopefully wrap up by the end of June with a closed beta for those interested w/ public launch end of summer / Q3.
To support distribution across the Android ecosystem and desktop configurations part of TyphonRT is a PaaS system such as when a TyphonRT app is installed it will download any OS or device specific modifications / alternate components to "patch" or provide a stable middleware layer in attempt to keep that write once / run anywhere promise or get as close as possible.
Of note I'll also be dumping over 10 years of solid Java real time app / game dev knowledge too through an expanding tutorial series w/ lots of code examples styled in a similar manner to Khan Academy.
http://www.typhonrt.org/
Ok not to hijack this thread, but the work I am doing as an indie / startup is relevant to this discussion. This kind of solution with the current landscape surrounding Java is only going to come from the open source / indie area.
Sounds kind of like Marimba on steroids. I like the notion of it running on Android 1.6, if I could drive the price down for a 1.6 capable module to sub $25-$35 I think I've got an enterprise use for it :-)
From my experience, Java applets are slow. The loading time to load the actual JVM is a pain. Because of that I haven't installed Java in many years. If I come to a site that asks me to install Java, I just go to another site. There's your portability problem.
I think you will find that total market share of FireFox, Chrome and safari now exceed IE
FireFox and Chrome nearly do it themselves.
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
Internet Explorer (43.2%)
Mozilla Firefox (28.6%)
Google Chrome (14.6%)
Safari (6.3%)
Opera (2.6%)
Mobile browsers (4.7%)Mobile browsers are just 4.7%? Wow. I would have thought they'd be about 25% now.
It may be hard to count. I change my user agent on my phone so that I don't get the mobile version if websites. With current phone resolutions I prefer to see the full page and zoom than have an often crappy mobile specific site that shows me less and makes me click more.
I wonder where does Firefox for Android falls under, Firefox or mobile browsers? Although I don't know if it's significant, but when I last checked AppBrain, Firefox for Android had over 250,000 downloads.
Yea it's a mess.
Google is going in an interesting direction with Native Client, Pepper, Go-lang and ChromeOS. I remember them (might have been Brin) saying web and desktop will merge and looking at Native Client, the capabilities should merge as well.
Mozilla has their own simplified systems programming language, Rust. They're cooperating on with Google on Pepper so far. In theory browsers could just become agreed upon APIs between operating systems instead of the markup/VM legacy mess they are now.
Google is going in an interesting direction with Native Client, Pepper, Go-lang and ChromeOS. I remember them (might have been Brin) saying web and desktop will merge and looking at Native Client, the capabilities should merge as well.
Mozilla has their own simplified systems programming language, Rust. They're cooperating on with Google on Pepper so far. In theory browsers could just become agreed upon APIs between operating systems instead of the markup/VM legacy mess they are now.
(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
As long as native apps have access to parts of the platform off-limits to web apps there will be a place for them.
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
As long as native apps have access to parts of the platform off-limits to web apps there will be a place for them.
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.
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?
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?
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.
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.
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.
90% of the apps I have seen people proudly swag around with on their iPhones and Androids could simple be rewritten using html5+css3, very very few of them made use of any mobile-device specific sensors or drivers.
You're 100% right from a technical standpoint, but it's a bit hairier on the UI design side.
A huge strength of iOS is that most iPhone apps look and behave like most other iPhone apps, and that's because of the coherency provided by the UI framework and HIG. Asking developers to write their own CSS styling for widgets would result in a much more fragmented experience from app to app, which would detract from the platform as a whole (on top of a whole other slew of tiny UI touches added to UIKit, like the surprising complexity of the view-to-view transitions in CoreAnimation, that would be lost on 99% of app developers if asked to develop their own animations).
One of the most interesting things Apple is working on that everybody seems to ignore is iAd Producer. They've basically created a full-fledged HTML5 app-building tool that recreates a large part of UIKit in JavaScript, but it's currently only good for iAd development. I'd love to see what would happen if they would let developers release apps built with the tool.
A huge strength of iOS is that most iPhone apps look and behave like most other iPhone apps, and that's because of the coherency provided by the UI framework and HIG. Asking developers to write their own CSS styling for widgets would result in a much more fragmented experience from app to app, which would detract from the platform as a whole (on top of a whole other slew of tiny UI touches added to UIKit, like the surprising complexity of the view-to-view transitions in CoreAnimation, that would be lost on 99% of app developers if asked to develop their own animations).
One of the most interesting things Apple is working on that everybody seems to ignore is iAd Producer. They've basically created a full-fledged HTML5 app-building tool that recreates a large part of UIKit in JavaScript, but it's currently only good for iAd development. I'd love to see what would happen if they would let developers release apps built with the tool.
That's true but I'm also seeing a trend away from using Apple's native widgets in a lot of apps. I think users have seen them enough now that they see standard UI elements as generic and indicative of a boring or low-quality app. The leaders mostly seem to have rolled a lot of their own look & feel, even if it's just image-backed UIButtons.
You're already starting to see this. For example, this web app: http://html5photos.appspot.com/ when viewed on recent generation android phones utilizes hints in the markup to trigger the phone camera for uploading. I think we will see this sort of integration continue. Will it be a pain dealing with proprietary markup across browsers? Sure, but it will still be faster than writing multiple native applications.
Have you ever heard of PhoneGap? http://www.phonegap.com
It seems just a matter of time before APIs for these become part of HTML5.
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.
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.
Yep. We already have access to GPS location data in HTML5.
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.
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.
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.
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.
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.
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.
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.
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.
The article confuses the tech with the marketplace. Not the same thing.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
Both VMs you mention are too heavy and not real standards.
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.
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.
Heaviness comes from use cases, not intrinsic
properties.
The Java world is "standardized" (de facto, since
it's not a "real" standards board, but still)
.NET, you have ECMA-335 specifying the CLR and
ECMA-334 specifying the C# language itself;
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 ...
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.
The relative ease of interface design?
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.
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.
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.
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.
I'm afraid we wont ever get there, not with current implementations / DOM / js, whatever. Which makes me sad.
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.
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
//Disgruntled js developer
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.
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.
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.
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.
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 ;).
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 ;).
The web is full of great, crisp user interfaces, and no one questions that. It's just that they don't run (as well) on mobile devices. That's a function of the devices and their software; not the technologies of the web. Projecting that to continue indefinitely seems short-sighted.
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.
The more things change the more they stay the same.
This reminds me "Shortchanging Your Business with User-Hostile Platforms" 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.
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.
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?
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?
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?
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?
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)?
[deleted]
i'm pretty sure you can't replace something graphically intensive as Unreal's Infinity Blade with a cross-mobile-browser web app.
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.
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?
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?
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.