I've recently been involved in some conversations around the "lock-in" provided by the mobile system development platforms: once you start working towards (for example) an Android app, it's going to be an Android app. Deploying it on another platform generally means that you have a lot of porting work to do, and multiple codebases to maintain.
I think that's yesterday's model. I think the model for the future is "web apps," by which I mean applications developed using HTML5, JavaScript, and the various APIs coming out of the W3C.
An objection I've heard raised here -- actually, two different objections, but with the same root -- is (1) people don't want to open their web browser and surf to a web page to run their programs, and (2) the mobile web browsing experience is not terribly convenient.
What's critical to realize is that "web apps" aren't necessarily bound to the experience of "opening up a web browser as an explicit action, navigating to an application's web site, and then interacting with it as if it were a web page." Web-apps-as-first-class-apps is a viable model for development and deployment. And there is a team of people inside Mozilla who are working really hard to make this work as seamlessly as possible.
Both FirefoxOS and BlackBerry 10 inherently treat HTML5/JavaScript applications as "first class" apps. In FirefoxOS, it's the sole means of developing applications; and BlackBerry 10 uses it as one of several native development environments. In both cases, the user's experience is indistinguishable from what they're used to apps doing: there isn't even an intermediating browser anywhere in the mix. The HTML5 and JavaScript engines are an inbuilt part of both operating systems.
I recognize that neither platform has the penetration to be a real game changer; at least, not at the moment. I'm holding them up as existence proofs that the approach of "web app as native app" is viable. But let's talk about how these technologies can be leveraged for native webapp deployment on Android, iOS, and Desktop systems.
All of these systems have their own idea of "installed applications." To be successful, we need some way to make these HTML5/JavaScript applications look, act, and feel like every other kind of application (rather than "something running in a web browser").
This is where the work that Mozilla has been doing for web app deployment comes into play, and it's easier to demonstrate than it is to explain. If you have Firefox installed on your desktop (or Firefox Aurora on your Android device), you can go to https://marketplace.firefox.com/, find apps that amuse you, and click on "install." At that point, Firefox takes the steps necessary to put an icon in whatever location you're used to finding your applications. On your Android device, you get an application icon. Under OS X, you get a new application in Launchpad. For Windows, you get... well, whatever your version of Windows uses to access installed apps.
From that point forward, the distinction between these web apps and native applications is impossible for users to discern.
Interestingly, iOS was both a bit of a pioneer in this space, and also remains the most frustrating platform in this regard. If you recall Apple's stance when the original iPhone first launched, they didn't allow third-party applications at all. Instead, their story was that HTML and JavaScript were powerful enough to develop whatever applications people want to write. Presumably as part of this legacy, iOS still allows users to manually save "bookmarks" to their desktop. If the content behind those bookmarks is iOS-aware, then the bookmarks open in a way that hides the browser controls -- effectively acting like a native app. If you have an iOS device, you can play around with how compelling this experience can be by going to http://slashdot.org/ -- select the box-and-arrow icon at the bottom of your browser, and click "Add to Home Screen." Now, whenever you open the newly-created icon, it acts and feels exactly like you downloaded and installed a native "Slashdot" application onto your device. It even appears in the task management bar as a separate application.
The reason the iOS experience remains frustrating is twofold. First, and primarily an annoyance to developers: the only HTML5/JavaScript rendering engine allowed on the platform is Apple's own webkit implementation. This frustrates the ability to add new APIs, such as may be required for new applications. So, new APIs are only added at whatever pace Apple's product plan gets them added. Secondly -- and of actual concern to users -- there is no programmatic way to add web app icons to the desktop. Creating these icons requires a relatively arcane series of user steps (described above). Basically, Apple is playing the role of the napping hare in this tortoise-and-hare race: they were very fast out the gate, but have been asleep for quite a while now.
But that covers all the bases: it's possible to develop HTML5/JavaScript apps that truly run cross-platform for iOS, Android, Blackberry, FirefoxOS, and a variety of desktop systems -- even if the Apple experience is somewhat less than satisfying (for both developers and users).
I suspect most of what's holding developers back is predominantly a lack of knowledge that this is a viable technical model. I've heard developer feedback that one major reason they aren't targeting JavaScript environments involve concerns about the speed of execution in a JavaScript environment. It's not yet clear whether these problems are merely perception or reality. I've seen some impressive things like usable cryptography, high-def video codec decoding, and high-performance first-person 3D environments (including viable multiplayer first-person shooters) implemented in pure JavaScript, so I suspect it's more a perception problem based on very outdated experiences. I'd love feedback from anyone who has run into performance problems trying to use this model with a modern JavaScript interpreter.
I think that's yesterday's model. I think the model for the future is "web apps," by which I mean applications developed using HTML5, JavaScript, and the various APIs coming out of the W3C.
An objection I've heard raised here -- actually, two different objections, but with the same root -- is (1) people don't want to open their web browser and surf to a web page to run their programs, and (2) the mobile web browsing experience is not terribly convenient.
What's critical to realize is that "web apps" aren't necessarily bound to the experience of "opening up a web browser as an explicit action, navigating to an application's web site, and then interacting with it as if it were a web page." Web-apps-as-first-class-apps is a viable model for development and deployment. And there is a team of people inside Mozilla who are working really hard to make this work as seamlessly as possible.
Both FirefoxOS and BlackBerry 10 inherently treat HTML5/JavaScript applications as "first class" apps. In FirefoxOS, it's the sole means of developing applications; and BlackBerry 10 uses it as one of several native development environments. In both cases, the user's experience is indistinguishable from what they're used to apps doing: there isn't even an intermediating browser anywhere in the mix. The HTML5 and JavaScript engines are an inbuilt part of both operating systems.
I recognize that neither platform has the penetration to be a real game changer; at least, not at the moment. I'm holding them up as existence proofs that the approach of "web app as native app" is viable. But let's talk about how these technologies can be leveraged for native webapp deployment on Android, iOS, and Desktop systems.
All of these systems have their own idea of "installed applications." To be successful, we need some way to make these HTML5/JavaScript applications look, act, and feel like every other kind of application (rather than "something running in a web browser").
This is where the work that Mozilla has been doing for web app deployment comes into play, and it's easier to demonstrate than it is to explain. If you have Firefox installed on your desktop (or Firefox Aurora on your Android device), you can go to https://marketplace.firefox.com/, find apps that amuse you, and click on "install." At that point, Firefox takes the steps necessary to put an icon in whatever location you're used to finding your applications. On your Android device, you get an application icon. Under OS X, you get a new application in Launchpad. For Windows, you get... well, whatever your version of Windows uses to access installed apps.
From that point forward, the distinction between these web apps and native applications is impossible for users to discern.
Interestingly, iOS was both a bit of a pioneer in this space, and also remains the most frustrating platform in this regard. If you recall Apple's stance when the original iPhone first launched, they didn't allow third-party applications at all. Instead, their story was that HTML and JavaScript were powerful enough to develop whatever applications people want to write. Presumably as part of this legacy, iOS still allows users to manually save "bookmarks" to their desktop. If the content behind those bookmarks is iOS-aware, then the bookmarks open in a way that hides the browser controls -- effectively acting like a native app. If you have an iOS device, you can play around with how compelling this experience can be by going to http://slashdot.org/ -- select the box-and-arrow icon at the bottom of your browser, and click "Add to Home Screen." Now, whenever you open the newly-created icon, it acts and feels exactly like you downloaded and installed a native "Slashdot" application onto your device. It even appears in the task management bar as a separate application.
The reason the iOS experience remains frustrating is twofold. First, and primarily an annoyance to developers: the only HTML5/JavaScript rendering engine allowed on the platform is Apple's own webkit implementation. This frustrates the ability to add new APIs, such as may be required for new applications. So, new APIs are only added at whatever pace Apple's product plan gets them added. Secondly -- and of actual concern to users -- there is no programmatic way to add web app icons to the desktop. Creating these icons requires a relatively arcane series of user steps (described above). Basically, Apple is playing the role of the napping hare in this tortoise-and-hare race: they were very fast out the gate, but have been asleep for quite a while now.
But that covers all the bases: it's possible to develop HTML5/JavaScript apps that truly run cross-platform for iOS, Android, Blackberry, FirefoxOS, and a variety of desktop systems -- even if the Apple experience is somewhat less than satisfying (for both developers and users).
I suspect most of what's holding developers back is predominantly a lack of knowledge that this is a viable technical model. I've heard developer feedback that one major reason they aren't targeting JavaScript environments involve concerns about the speed of execution in a JavaScript environment. It's not yet clear whether these problems are merely perception or reality. I've seen some impressive things like usable cryptography, high-def video codec decoding, and high-performance first-person 3D environments (including viable multiplayer first-person shooters) implemented in pure JavaScript, so I suspect it's more a perception problem based on very outdated experiences. I'd love feedback from anyone who has run into performance problems trying to use this model with a modern JavaScript interpreter.
