It's certainly a fascinating piece of tech and a very politically intriguing play by Google, but I don't see it suddenly changing the calculus of app development. Here's why: the set of apps that I run on my phone are disjoint from the set of apps that I run on my laptop or desktop. My laptop doesn't need a flashlight, or turn-by-turn navigation, or the ability to hail a cab, because I don't have it out or open or even with me when I do the things that need these apps. My phone doesn't need Photoshop or Notepad++ because the form factor doesn't favor it. Write-once-run-everywhere isn't a selling point for your app because I don't actually want to run it everywhere.
The one exception could be games, which are a lucrative market. That said, mobile games will offer a limited set of interactions compared to typical PC offerings, which will limit appeal to people who are already playing mobile games but who wish to play those games on their desktop as well. It will increase time spent in the app, but not grow the market substantially relative to new users coming in from mobile devices. And because it requires a browser anyway and because ARC is never going to run on iOS, if the web can advance fast enough to keep the market satisfied (asm.js is a start, but payment is still horribly lacking) then there will be pressure to just do everything on the web anyway.
I've done a fair bit of HTML5 game development for Mobile. And it's really tricky to get Mobile-first games to be fun on Desktop. All my games run on Desktop, but things like Flappy Bird just don't get much playtime on Desktop, it's popular because they're played in 'throwaway-time' on the bus, or in a bar when your friend is waiting in line to buy some drinks. A lot of mobile gaming is like that.
Which is why we don't see a ton of HTML5 games on desktop. Expectations for desktop games are far higher nowadays. If you're competing with a household-gaming experience (i.e. desktop games are generally played on your home computer), we're talking about competition like World of Warcraft, League of Legends, shooters, RPGs, or indeed big budget console games.
And seeing as any of these games can also run on your phone, and seeing as most gamers have phones nowadays, and seeing as your phone gives you a touch-screen experience around which the gameplay is built (e.g. swipe to throw a basket ball), you might as well play on your phone.
There are some exceptions, but not many. At the end of the day though, if the mobile game runs on your phone and desktop, you'll play it on your phone. If the game has a mobile version and a desktop version, and the mobile also runs on your desktop, you'll play the desktop version instead on your desktop. Mobile games on desktop is likely a relatively small market.
Of course this entire thing will shift slowly once you can run mobile games on your desktop. But it won't be a gigantic thing overnight. It's years away.
And considering I fully agree with all your points (Flashlight, nav, cab, Photoshop and Notepad++ are excellent examples of the divide) I think it'll take quite a bit of time before things take a big turn.
It kind of feels like the early Android tablet days. When the tablet app store offered just blown up phone apps. This is going to be that, but even more blown up, and much less finetuned to the mobile form factor. (e.g. things like swipe based UI just doesn't fly.) Of course it was clear that one day developers would build apps that'd adjust to both phones and tablets perfectly, but it took some time and it's still not quite there yet. This will be similar but I think it'll take a little longer, as it's not just a resolution-difference, but also requires developers to build multiple control systems (like swipe). The entire fat-finger vs precise-mouse driven UI/UX divide now needs to converge and it takes time.
In any case, the latest announcement of touch-screen Chromebooks makes a lot more sense now.
HTML5 desktop games barely exist. If you build a game for desktop you usually just build a native game, because trying to build World of Warcraft or GTA in a browser makes little sense. And if you do build for the browser, it's usually small-mid games where Flash is still king, despite the fact it's dying.
Desktop HTML5 games are afaik 90% mobile HTML5 games that obviously also run on Desktop, but to call 'em desktop games would be too generous because they're built for crappy mobiles running Android 2.3 browsers where even playing a simple sound when you press 'start game' is a big deal because you have a few megabytes of memory to work with. A lot of these games cater to e.g. 40 year old house moms who want to play Candy Crush type games but outside of the App Stores that are marketing black boxes.
Big publishers in this scene are e.g. Spil Games or BoosterMedia.
Beyond that, there are a few developers who build cool HTML5 games usually as a way to get you to download their native app. It allows them to put these games on any desktop gaming portal, the Facebook canvas etc, and get eyeballs, and then after 5 levels say 'download the native app for more'. But even then devs often go with Flash as it's got such a huge community of developers with lots of expertise, and with Flash dying, it's cheap to hire.
For example, I think Kingdom Rush, a pretty cool and fun native tower defender app on mobile had an HTML5 version in the Chrome store, basically as an extra channel to advertise their mobile app. Not completely sure though.
Again these are mostly just desktop games that got an export-to-html5 version, though. A lot of the entry level game dev tools like GameMaker or Scirra seem to have built a big HTML5 engine which allows them to offer their users an export to iOS and Android apps by wrapping them with tech like cordova, without having to mess with Objective C or Java or anything. So for a lot of indie game devs that use this type of software they can export to HTML5 as an afterthought and upload it.
Don't know of big HTML5 game repos other than the mobile-first publishers (SpilGames, BoosterMedia, Keygames, Admeen, Pakap etc etc). There are some HTML5 game repos but they're full of crap.
Thing with HTML5 is, it's not a user-demanded tech. It's a developer tech for people who want '1 codebase, all platforms that have a browser', i.e. TVs, phones, tablets, PCs, consoles. No user is actually interested in playing HTML5 games, it has no known benefit to them, so it's never advertised as such and so there's no real stores built around it.
That's a nice analysis! I'm also into browser games. But just started with "HTML5". The reason is that it takes time to invest in new technology. "HTML5" is bleeding edge and new features are still added. WebGL is not yet fully supported on the major browsers and Canvas just got hardware acceleration a year ago. Also Websockets got scandalized just months ago. Flash on the other hand, is mature, so it will live on at least a few more years as a lot of developers are still developing in it.
I think Google deliberately slowed down "HTML5" in favor for their Android ecosystem. Witch was a stupid idea since most of their money still comes from WWW.
The money is still in WWW! The the problem is that a native app runs much better then a web app on Android. Even Facebook made a native app!!
With Chrome-OS and Firefox-OS on mobiles we might be able to reduce the gap between native and web on mobiles.
Native is still king on desktop though and I do not think AAA-studios will develop for the web anytime soon.
There are some studios (Zynga, King) making shit-loads of money from crappy web-games though, so I think we will see more in between crap and AAA on the web soon. And hopefully without plugins!!!
Isn't there something in between weekend-project demo games that you master in 5 minutes and AAA games with million dollar budgets? Also I disagree with this:
> Thing with HTML5 is, it's not a user-demanded tech. It's a developer tech for people who want '1 codebase, all platforms that have a browser', i.e. TVs, phones, tablets, PCs, consoles. No user is actually interested in playing HTML5 games, it has no known benefit to them, so it's never advertised as such and so there's no real stores built around it.
I'm a user and I want it. The ability to play a game on any computer without installing Steam and then installing the game and then setting up a controller and etc. etc. is a huge win for users.
I understand that browsers aren't ready for AAA FPS games (or at least the makers aren't ready to put the effort into html5 export) and I'm fine with that, but I think there's something in between, like a Super Meat Boy that is still a full-fledged game and can easily work in browsers.
I'm just surprised that there are virtually none of these out there.
As you say, there's a class of apps that works best on a phone and another that works best on a laptop. But there's also a class of apps that you'd want to run everywhere, for example all the addictive social media apps. For these it becomes more of your preference between touch vs point and click interfaces. This is what Windows has been trying to do, offering both paradigms in one device. I've talked to people with these Window devices who will switch between using the full-screen/touch and the windowed/mouse version of the same app based on their context. It's nice to have the options.
I could certainly be wrong! That said, I don't see Google themselves really committing to such an effort (there are definitely business incentives to do it, but it sounds like a terrible technical burden). There could be third-party products that make it happen, but from my experience they would likely either be expensive or result in a janky product (or both).
I think you may be underestimating the overlap between smartphone and desktop functionality. Take a look at the home screen of your smartphone - what percentage of those apps are also available as a web app? For me that figure is about 80%.
Amusingly, for me, there's exactly one app with a web equivalent that's not a preinstalled Google app (a weather app). The rest all are either doing things with hardware that the web doesn't know how to access (accelerometer, microphone, camera, FM radio, SMS, cell, raw network access), or apps for managing data on the phone itself (contacts, image gallery), or services with no web equivalent (Steam, Lyft).
And that's just the thing: if your app can be done on the web, you're already going to do it on the web, because there's not a platform on the planet that won't automatically have it. If the website that you already have doesn't perform well enough, then you make a second app while you wait for the web to reach parity.
You're going to think I'm weird, but I don't use the Facebook app, I use the site. I don't use the Twitter app, I use the site. This isn't some philosophical choice on my part, I really just can't be arsed to take the effort to search for yet another app on the app store, and then fret over the implications of approving yet another set of meaningless permissions, and then resign myself to endure yet another app pestering me to update it for the rest of my days.
I accept that there will always be a place for native apps. The web is slow to pick up on new bits of hardware and new modes of interaction, so native will always be ahead of the pack there (though Mozilla is at least attempting to prepare itself for the Oculus Rift with a big push for VR on the web). It's a conservative platform. But once something is Good Enough for the web, you need a very good reason to dislodge it.
We are clearly polar opposites because I love native apps ;) For example you might think The Economist was perfectly suited to a browser web 'app', but I prefer the native Android app because (a) it notifies me when a new issue is published; (b) it downloads the content offline; (c) it is fast to navigate and has smooth animations between pages.
I think we've been talking about two separate issues:
1. Do a significant proportion of apps need to provide the same functionality on both a smartphone and on desktop computers? Here I think the answer is yes. Twitter, Gmail, weather apps, maps, image gallery, music streaming, games, banking apps, youtube, etc. provide essentially the same feature set on both devices.
2. If an app needs to run on both smartphone and desktop, should it be native or a web app? Here I think the answer is not so clear-cut. Certainly in the past 15 years it was true that "if your app can be done on the web, you're already going to do it on the web, because there's not a platform on the planet that won't automatically have it". But will that still be the case in 5 years time? The choice of platform for a new app depends on more than just the potential number of users - the usability and development cost also matter. Let's say I expect to produce a web app, an iOS app and an Android app - is it really worth the extra cost to produce the web app if I can cover 95% of the potential user base without it?
> But will that still be the case in 5 years time?
By 2020 I don't expect any new platform to arise that both lacks a standards-compliant web browser and manages to enforce the lack of such a web browser. I also don't expect any existing platform's browsers to regress from the degree of standards compliance that they have at this moment. There do exist several scenarios whereby web standards could stagnate over this time period:
Scenario 1: A major platform allows only a single browser, that browser being produced by the platform's parent company, and drags its feet in order to impede the standards process and promote native app development over web app development. The obvious potential candidate here is iOS, with Safari being the last major browser that has yet to commit to an "evergreen" model whereby features are quickly and regularly released. However, if ARC were to ever pose a threat to Apple's app model such that they could not somehow counter it with crippling technical constraints, it would be in their best interest to rapidly advance Safari to feature parity with other browsers. In other words, if Apple were ever faced with the decision of empowering the web vs. tacitly empowering a platform backed solely by Google, they're always going to choose the web.
Scenario 2: Chrome becomes dominant to the same degree that IE6 was once dominant. At this point anything that Google decides to implement (or to not implement) would de facto determine web standards, and just like Microsoft of old they could choose to leverage this power in order to advance a proprietary platform under their exclusive control. This is largely kept in check by Chrome's inability to exist on iOS as anything other than a thin wrapper over Safari, a situation that is unlikely to ever change (at least, I don't see any business motive to Apple making such a thing possible).
Scenario 3: Mozilla somehow loses its seat at the standards table. In the short term it may seem like Firefox can be ignored to a degree, but in the long term Mozilla is the Bismarck that keeps web standards moving forward in ways that are seen as beneficial to a majority of the vendors at the table. As long as there exist platforms with sizable userbases on which Firefox can be installed, it is in Mozilla's interest to advance the web as quickly as possible while convincing two of the big three to play along in order to undermine the remaining mutual competitor (and hence indirectly gaining an influence over that competitor's closed platform, using the browser as an attack vector). Mozilla's recent contract with Yahoo will sustain their efforts at their current levels for at least another five years, but its fate beyond that time will depend on how well FirefoxOS does at keeping Firefox from being locked out of the increasingly closed platforms of the future.
Given all of the above, I think it's safe to say that the web will continue to evolve rapidly for at least another five years, and the inexorable advance of mobile hardware will continue to close the gap between native performance and web performance (with projects like Mozilla's Servo designed to accelerate the closing of this gap). In the meantime, the biggest hurdles are the process of web app development (sorely lacking compared to native development, though there appear to be tentative steps in the right direction) and the unanswered question of how to make payment on the web as frictionless as it is on mobile (seriously, someone start working on this).
Yes the three scenarios you mention are unlikely, and I agree that the web will continue to evolve rapidly for at least another five years. But isn't it possible for web apps continue to close the performance gap yet still lose their dominance as the 'first choice' for startup development?
For example, perhaps Google will make it much easier to port an Android app to iOS, similar to the way SWT makes it easy to write a single app that uses native controls on both Mac and Windows.
This Android+iOS app could then run on Windows, Mac, ChromeOS, Linux, Android, and iOS. Suppose that the cost of developing such an app is roughly equal to the cost of developing a web app. Wouldn't startups be tempted to choose this platform over a web app?
The one exception could be games, which are a lucrative market. That said, mobile games will offer a limited set of interactions compared to typical PC offerings, which will limit appeal to people who are already playing mobile games but who wish to play those games on their desktop as well. It will increase time spent in the app, but not grow the market substantially relative to new users coming in from mobile devices. And because it requires a browser anyway and because ARC is never going to run on iOS, if the web can advance fast enough to keep the market satisfied (asm.js is a start, but payment is still horribly lacking) then there will be pressure to just do everything on the web anyway.
Interesting times are in store, regardless.