This might come as a surprise to anyone who uses an iPhone, an Android handset, a Windows Phone device, or even a BlackBerry, er, BlackBerry. All of these have good browsers with rich HTML5 support. Isn't the Web already on mobile?

Obviously the answer is yes, but there is nonetheless some truth to Kovacs' hyperbolic statement. More often than not, when developers want to target mobile users, the response is, as Apple would say, "There's an app for that." As such, portable, location-aware smartphone software—think the Starbucks loyalty card app, or Instagram—tends to work only in an app, or at least work best in an app. Mobile Web sites, in contrast, are either non-existent, or feature deprived.

The result is that the smartphone application market is effectively controlled by two players: Apple and Google. Kovacs says that this is leaving "many needs [...] unfilled," and that instead of "one or two providers approving content" there should be "many app stores, many business models, many payment mechanisms, many providers, many services."

Mozilla CEO Gary Kovacs

Mozilla

Firefox OS is designed to run Web apps, developed using standard Web technology. In this way, it avoids the platform lock-in and vendor-dependence that Apple and Android both have, and so enables the kind of fragmented, diverse world that Kovacs envisages.

Mozilla has arguably done this before. Kovacs argues that Mozilla made the Web open. While that too seems initially hyperbolic, it's not too far divorced from reality. In the 2000s, Firefox broke the back of the "Designed for Internet Explorer 6" mindset. Mozilla took on the Internet Explorer monopoly, and actually succeeded in making the Web a place for cross-platform standards rather than single vendor dominance.

That was arguably an easier task, however. Getting existing Web devs to make relatively minor adjustments to ensure their code worked in Firefox as well as Internet Explorer is much simpler than asking app developers to discard their existing tools entirely, and switch to Web development.

In Kovacs' eyes, that's not a problem, as Firefox OS already has an enormous community of developers ready-made, courtesy of ten million Web developers that already exist. Firefox OS may not have any apps available today, in contrast to 700,000 for iOS, but Kovacs has a slogan in response: "There's a Web for that."

Mozilla's position has precedent, but none of it good. The original iPhone, though now consigned to the annals of history, did not support any third-party applications at all. The late Steve Jobs said that the iPhone SDK, such as it was, was the Web: HTML5 in Mobile Safari. After consistent push back from would-be iPhone developers, Apple relented, introduced the SDK and store, and arguably made third-party applications the central feature of the platform.

Palm tried a similar model with webOS. Although webOS applications were not "the Web" as such (they ran locally, and had access to various APIs not found in a browser), they were nonetheless Web technologies and so, in theory, well-poised to win the hearts and minds of existing Web developers. This never happened. Palm was sold to HP, and now webOS, a once promising, exciting smartphone platform, is faced with the indignity of a future as an operating system for TVs.

Also telling is the fact that Google, a company that is striving to push as much as it can onto the Web, and that even has an operating system that can do nothing but run a Web browser, Chrome OS, produced a smartphone platform that runs plain old apps in the same way as iOS.

Another kind of fragmentation could, however, be the weapon that gives Mozilla the fragmentation it seeks. The smartphone market is currently dominated by iOS and Android. Windows Phone and BlackBerry 10 are minor players fighting for survival, and soon they will be joined by Ubuntu and Firefox OS. There are also unknown wildcards such as Intel and Samsung's Tizen. Add tablets into the mix too, and there's also Windows 8 to consider. Even Chrome OS could become significant in the future.

Even modest success from these platforms—5 percent of the market each, say—would substantially alter the dynamics of the app market. An app developed for iOS or Android alone would sacrifice considerable market reach. Developing applications for four, six, or even more different platforms will drive up costs considerably. Faced with this, it's likely that developers will seek to consolidate somehow, to allow application code to be re-used across the many different platforms.

Systems such as Xamarin and PhoneGap, which still create "real" apps but allow greater code sharing, are one possible answer. But the Web is another answer, and the answer that provides the broadest reach of any platform. While other platforms might be able to co-opt it somewhat—it'd be trivial for the iOS App Store to add links to Web Apps, for example—the openness and flexibility would be inescapable.

Firefox OS's best bet for success, then, could be the success of other platforms. If they thrive, the Web itself thrives, and Firefox OS can find a role. If they don't succeed, however, Mozilla has an enormous mountain to climb, and this time around, it's hard to see how it will ever manage.

You can always sideload apps into Android devices. There are also alternative stores. Of course, as a developer, you'd be missing out on the massive userbase of Google Play, but the same problem would also exist in any web-based-apps store, so it's not really about technology.

The interesting thing is that this was Apple's original position. There were no native apps on the original iPhone, the intention was to have apps provided via the web. This would have removed the walled garden and Apple's need to curate the App Store.

In the end it wasn't enough and people jailbroke the iPhone and found ways to implement native apps regardless of Apple's involvement. Apple then released the dev kit and App Store with iOS 2 and the rest is history. Is the world now ready for the Firefox OS approach when is wasn't five years ago? Is there now sufficient network connectivity to support that model over the native app model? Time will tell.

You can always sideload apps into Android devices. There are also alternative stores. Of course, as a developer, you'd be missing out on the massive userbase of Google Play, but the same problem would also exist in any web-based-apps store, so it's not really about technology.

true, but how many android users side load apps?

Its never been if its possible, its about if open web has real impact for the platform as a whole. The dominance of android on mobile web is already affecting the web negatively, there are already many large websites coding their mobile sites specifically for webkit with a prefix, even when other browsers support the same standards.

What has been fought for in the early 2000s, an open web, is now being buried under another monoculture, no matter how elegantly the intention was stated by apple or google, the consequence is not much better than monopoly by microsoft.

Let me add the sad fact, I was writing to website complaining their websites only work in IE in 2002, I haven't done that since 2005. Imagine the surprise I have when I had to do this again last week to huffpost to complain their mobile web only works in webkit browsers. Its shocking, and indeed, sad.

The only reason native apps are so popular among developers is because they provide a concrete revenue model in the way the general web does not. Want to add block? So sorry, the app stops working. Hate ads? Well... it's *only $1.99...

But native apps in most cases are bad for users. There are some apps, like office suites, which work better than they would as web sites (especially in areas of spotty cell phone coverage), but so many apps are just front ends for web sites. Instead of writing web sites properly, you'll write and support another application? Ugh.

The only reason native apps are so popular among developers is because they provide a concrete revenue model in the way the general web does not. Want to add block? So sorry, the app stops working. Hate ads? Well... it's *only $1.99...

But native apps in most cases are bad for users. There are some apps, like office suites, which work better than they would as web sites (especially in areas of spotty cell phone coverage), but so many apps are just front ends for web sites. Instead of writing web sites properly, you'll write and support another application? Ugh.

How are native apps bad for users? They're likely to have better performance, better power usage and make more use of the platforms unique features.

I've used plenty of webview wrapper type apps and they all suffer from relatively poor performance and unpleasant frankenstein style UIs.

The appeal of html5 based apps is to *developers* not users as I understand it. But as a user, why should I care about that? For that matter, I don't see why I should care as a developer. More APIs means more jobs for programmers!

The problem is a lack of acknowledgment of the constraints you have when dealing with deployment. Devs didn't demand native apps because of some arbitrary, indefensible stubbornness. They demand native apps because it is the technical solution that makes sense.

You have a mobile processor with a small fraction of the processing power that you have on a desktop CPU. You can't always afford to be wasting CPU time with interpreters. You shouldn't always sacrifice the user experience to their current data connection.

The web model is always going to be less efficient than native code (unless you use a native code plugin, which defeats the web deployment model). I don't want to divert this into a Javascript flamewar, but I think most people would agree that getting compiled, native code performance out of a browser-based deployment is going to be very difficult (or load-time intensive in the event of a better JIT compiler).

On top of that, you have proprietary code protection, the need to pay for a web hosting service, the multi-environment management and cost of having your app distributed across a server and client - it starts to make very little sense to move many things that are apps in to the web environment. Some things that are apps probably shouldn't be. But not all things that are apps should move to the web.

I'm not saying it is impossible, or that "no one would ever want to do this" - but developers are not stupid. They will pick the technical solution that makes the most sense. Sometimes that is a web application, sometimes it isn't.

Is the world now ready for the Firefox OS approach when is wasn't five years ago? Is there now sufficient network connectivity to support that model over the native app model? Time will tell.

The question isn't network connectivity. HTML5 applications do not necessarily need an internet connection to function - there are lots of examples in the Chrome web store that show this. The question is whether the standard has progressed enough to give functionality comparable to native apps in most cases. I'm guessing the answer to that is no, sadly, though I whole heartedly support Mozilla's effort, because I really would like to see an open standard take over. If they can get HTML closer to being a usable replacement for native code, more power to them.

One of the biggest problems I always have with the "you don't need an app if you have a good mobile website" argument is that in my experience even the best mobile websites are limited because they can't make use of OS features. If I'm reading something on a website disguising itself as an app, and I want to share something, I bring up the menu via the phone's menu button, but that just gives me general browser options. If a website allows me to upload a picture, I have to manually switch to the camera app, take the picture, go back to the browser, somehow select that picture from the sd card, and upload. In a native app the app can just start the camera app and everything is seamless.

Say WhatsApp was a website instead of an app. How would I be able to select text or a picture in some application WhatsApp doesn't even know about and share it to one of my WhatsApp contacts? Native apps support this out of the box.

I suppose the guys behind Firefox OS thought about this too, but I'm not seeing anything addressing this problem in the article.

Another thing I don't get: if standard web technology suffices for mobile applications, and if using them only has advantages for developers, why would any of them decide to develop a native app at all? After all, this technology is available on all major platforms. Why aren't developers flocking to it, if it brings nothing but advantages over native? And if it doesn't: why does Firefox OS matter?

I suppose the guys behind Firefox OS thought about this too, but I'm not seeing anything addressing this problem in the article.

Heh, there's a reason for that

Stuff like camera support and open contacts are shawshanking their way through w3c so there may be a solution to that simple long-standing problem sometime in 2015 that'll be widely implemented about 2018-2020 or so. Yay?

Like Chrome OS, I believe that this is the future of the web but here before its time. The internet is not quite ubiquitous enough yet, and data plans aren't cheap enough yet, to have everything "on the web". It's getting damn close, but until I can boot up into a web-only platform and do everything that I could do in a Windows environment, the web won't be the only solution.

I've been a Chrome OS user; had several Chromebooks and liked them for what they were, which is a second/third computer that's cheap, easily replaceable, and highly portable. What they were and are not, in my opinion, are $1300 replacements for standard desktops and laptops.

In the end though I don't think that we as the average consumer are truly the target audience for these technologies.

I'm guessing the answer to that is no, sadly, though I whole heartedly support Mozilla's effort, because I really would like to see an open standard take over. If they can get HTML closer to being a usable replacement for native code, more power to them.

The problem is that this seem more driven by ideology than by what makes sense and practical. There will be cases where native code make more sense, and cases where something like HTML make more sense, which is the reason why we haven't switched everything to the HTML on our computers. Both iOS and Android have very decent HTML5 support, so it's not like Apple & Google are actively suppressing HTML "apps".

Unless the OS is offering something more tangible than "it's how it should be done" to the user users, I really don't see how it can take flight.

The end of your piece reminded me that Chrome OS has basically the same aim, just for laptops, not phones. Eventually we'll have a world where we can have the same operating system on our phone, tablet, laptop, desktop, <to be invented market segment>. Windows seems to be heading in that direction, it's ubuntu's big idea, I'm surprised Apple hasn't already gone further in this direction, and also surprised that Google sees Chrome OS and Android as operating in separate ecosystems.

So will Chrome move to phones, and will Firefox OS later move to laptops to compete with Chrome? That might lead to the "firefox effect" you described, where fragmentation/competition led to adoption of standards. Imagine if I could use the same "web app" on firefox OS, chrome OS, iOS, Android or any other OS!

I’m sitting in an office where my coworked have been working on a HTML5 game client so it could be "cross platform" (as much as possible anyway) and the only takeaway I get from all the LOUD cursing all the time is that HTML5/Web tech is not there yet, not by a long shot. Mind you, those are people with 5+ years of web development experience each (and some more "classical" dev experience), so it’s not some unluckies bumbling around with jQuery UI or some such.

So yeah, given how it’s not 2005 anymore and users actually have certain expectations regarding app quality and polish, HTML5 and web technologies have an uphill battle to fight as the development platform of choice. I understand Mozilla has to do _something_ to appear still relevant, but I don’t think their own Web OS platform is the answer.

The only thing that will kill apps are perpetual internet connectivity, high speed pipes that can download hi-def high quality video games, and the willingness of 100% of the public to give up the ability to download data to their local device.

In other words, apps will never die. They may fade in importance, but death will forever be an exaggeration.

They haven’t? I must be remembering things incorrectly, then, seeing how iOS is based on OS X and is sharing most of the underlying technology. Apple just figured "same OS" doesn’t need to mean "same UI", and so far their approach is, if not the correct one, at least not been proven wrong.

In other words, apps will never die. They may fade in importance, but death will forever be an exaggeration.

Yeah, the discussion reminds me a bit of the time Java was supposed displace native apps in 1997something because people thought it will be trivial to develop a framework that works well across everything, from a phone to a workstation. Well, it isn’t and HTML5 et al are not a solution to that write once, run anywhere wet dream, either. Not yet, at least.

The interesting thing is that this was Apple's original position. There were no native apps on the original iPhone, the intention was to have apps provided via the web. This would have removed the walled garden and Apple's need to curate the App Store.

In the end it wasn't enough...

All he has to do is make the web experience better than the app experience. Should be easy, right?

When I stop writing apps on devices and start learning HTML5 you'll know I agree with that. Now, back to Xcode.

Frankly, I don't see what's wrong with apps. Or even curated apps (if you choose to opt into that infrastructure and don't get it forced upon you by a provider who promises one thing and delivers another).

That's not to say that web apps cannot and should not be more useful, but I can't help but think that whatever mobile device you have, you're always going to get the best possible experience out of a native app that's been designed to take account of your device's strengths and weaknesses.

After all, the last time I heard someone _really_ bash on about 'write once run anywhere' was with Java. How's that working out as a cross system platform of choice that delivers a premium user experience wherever it goes, again?

The problem is that this seem more driven by ideology than by what makes sense and practical. There will be cases where native code make more sense, and cases where something like HTML make more sense, which is the reason why we haven't switched everything to the HTML on our computers. Both iOS and Android have very decent HTML5 support, so it's not like Apple & Google are actively suppressing HTML "apps".

Unless the OS is offering something more tangible than "it's how it should be done" to the user users, I really don't see how it can take flight.

I freely admit that it is ideology that makes me want some standard, be it HTML5 or something else, to overcome native apps. But saying, "Android and iOS support HTML5 already" misses the point. Mozilla is trying to improve HTML5 to the point that it is a reasonable replacement for native code in most circumstances. It's not right now. But with some help, it might be some day. That's the point.

I’m sitting in an office where my coworked have been working on a HTML5 game client so it could be "cross platform" (as much as possible anyway) and the only takeaway I get from all the LOUD cursing all the time is that HTML5/Web tech is not there yet, not by a long shot.

Nah, that's just Agile development good practice. Vent your irritation vocally rather than on the code

BasP wrote:

Say WhatsApp was a website instead of an app. How would I be able to select text or a picture in some application WhatsApp doesn't even know about and share it to one of my WhatsApp contacts? Native apps support this out of the box.

I suppose the guys behind Firefox OS thought about this too, but I'm not seeing anything addressing this problem in the article.

Firefox OS has an HTML5 api for accessing phone hardware and linking between apps, so you can do the same things with HTML5 on Firefox OS as with native code on other OSes

* node.js & common.js demonstrate it' viability outside the browser* we have html5 now (specifically the javascript api's under that umbrella)* mozilla's firefox os is like the incubator or catalist for finalizing the api's* javascript interpreters are far faster, with asm.js even equaling java (think: power efficiency)* with phonegap even packaging for ios is in place

to rival native (ios) apps the polish is probably not there yet, but finally all the pieces exist and need only more love...mozilla has shown their open way works, can break lock-in and above all they have the perseverance...

oh and not to mention that google drives the chrome os sledgehammer in the same direction.

Frankly, I don't see what's wrong with apps. Or even curated apps (if you choose to opt into that infrastructure and don't get it forced upon you by a provider who promises one thing and delivers another).

That's not to say that web apps cannot and should not be more useful, but I can't help but think that whatever mobile device you have, you're always going to get the best possible experience out of a native app that's been designed to take account of your device's strengths and weaknesses.

After all, the last time I heard someone _really_ bash on about 'write once run anywhere' was with Java. How's that working out as a cross system platform of choice that delivers a premium user experience wherever it goes, again?

it will be in the details. local apps wont go away anytime soon, but who has to say they have to be native? java now runs 70% of the smartphone world and it is not native. its just been shown that javascript can be run as fast & efficient as java. obviously native is more efficient but for most apps thats not necessary.

secondly 'write once run anywhere' has always been a bad idea, but write 70% once and 10% for each platform would be far better... not to mention reusing stuff from the website...

The interesting thing is that this was Apple's original position. There were no native apps on the original iPhone, the intention was to have apps provided via the web. This would have removed the walled garden and Apple's need to curate the App Store.

In the end it wasn't enough and people jailbroke the iPhone and found ways to implement native apps regardless of Apple's involvement. Apple then released the dev kit and App Store with iOS 2 and the rest is history. Is the world now ready for the Firefox OS approach when is wasn't five years ago? Is there now sufficient network connectivity to support that model over the native app model? Time will tell.

The difference is that, just like with WebOS, web apps are first-class. In fact, almost all system apps are web apps. This is very different from iOS, where web apps are online-only and very limited.

It will be interesting to see if things improve with HTML 5 over time. I know companies such as Facebook had tried to go that way with their mobile Apps, but they reverted to native code instead due to performance and the end user experience.

The best thing I can say about HTML5 DOM as s general purpose application platform is that it sounds like a really good idea in theory. I used to be a big fan of this idea, back in 2011.

Then last summer I actually built a mobile app using HTML5 tooling. I started with Sencha Touch and then abandoned that for jQuery Mobile. It was a nightmare I don't care to relive. I dislike Java with a passion, and I still prefer the Android SDK.

If you think this is the easy way forward for app developers, you're kidding yourself. HTML5 has a Z-shaped learning curve. It's easy to do simple things, but you quickly reach a point where the frameworks don't do what you need out of the box, and once you resort to mucking around with raw HTML5 and CSS, you realize that now you're working at a lower abstraction level than you would be in a native SDK.

So that's why I think that Ubuntu and Sailfish have the right idea with the Qt object model scripted in declarative JavaScript (QML). It uses the same language and a similar paradigm compared to Sencha Touch or Enyo or any number of other HTML5 frameworks, but the object model is considerably more abstract and expressive, and the potential for performance and power optimization is much greater.

If web developers can't grok QML then good luck building anything of any significance in HTML5...

"Web app" is just another way of saying "permanently dependent on somebody else's computer (and goodwill) on a minute to minute basis, with that person having all of your data and seeing every single action you take".

it will be in the details. local apps wont go away anytime soon, but who has to say they have to be native?

Well they don't - there are some apps out there that pretty much are just front ends for 100% web data. These are obvious candidates for HTML web apps, for example. But...

bernstein wrote:

java now runs 70% of the smartphone world and it is not native. its just been shown that javascript can be run as fast & efficient as java. obviously native is more efficient but for most apps thats not necessary.

But can Java and Javascript run as fast as C++ or ObjectiveC? Now all the speed/code efficiency implied there might not be needed all the time, but when it's needed it might well be *really* needed.

bernstein wrote:

secondly 'write once run anywhere' has always been a bad idea, but write 70% once and 10% for each platform would be far better... not to mention reusing stuff from the website...

Only if the "10% for each platform" doesn't end up compromising the user experience on that platform.If a cross-platform app failed to implement something that would make the app a real hit on Android (for example) because a corresponding feature doesn't exist on iOS and adding it would be too much effort on a cross-development model then that's a bad thing.

My experience of Java, as someone who deals with a *lot* of enterprise java stuff, is that the original cross-platform aspirations have turned into "equally bad on all platforms". But this isn't about language - it's about making the best of the abilities of the device you're running on, which is always going to be harder on some cross-platform web app regardless of what framework you use.

Say WhatsApp was a website instead of an app. How would I be able to select text or a picture in some application WhatsApp doesn't even know about and share it to one of my WhatsApp contacts? Native apps support this out of the box.

I suppose the guys behind Firefox OS thought about this too, but I'm not seeing anything addressing this problem in the article.

Firefox OS has an HTML5 api for accessing phone hardware and linking between apps, so you can do the same things with HTML5 on Firefox OS as with native code on other OSes

So Firefox OS apps will need to be programmed specifically for Firefox OS and won't run on Android, iOS, WP8, or BB?

So Firefox OS apps will need to be programmed specifically for Firefox OS and won't run on Android, iOS, WP8, or BB?

How is this better than native apps?

Again, the real hope here is that the browser becomes the standard that people code to, instead of Android, iOS, Windows, or whatever. Mozilla is in the process of taking these improvements to HTML5 and making them standards, so that all HTML5-capable browsers implement them. Then you don't have to worry about re-writing your code for different platforms, because any platform that has a browser can run your code. That's the point of Firefox OS and Chrome OS, and I think it's a very worthwhile aspiration. There's a long way to go to get to the point where web standards are good enough, and people are right to point out that Java already tried this and it didn't turn out as well as hoped, but I vigorously applaud them for trying. And I think that the web is in a better position to standardize application development than Java ever was. We'll see in a few years how this turns out.