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.
One of the biggest strikes against HTML5 apps on iOS is that outside of the actual Safari browser, the JS JIT cannot be enabled, so JS performance is going to suck :-(. It's a transparently obvious move to drive developers to iOS native apps.
ReplyDeleteRobert: I think you're confusing two issues. What you say is correct for *native* apps that want to embed UIWebView: they're stuck with Apple's old, slow JavaScript interpreter. This is why, for example, Mobile Safari takes ~20,000 ms on the Kraken benchmark, while Chrome takes ~100,000 ms (both on a iPhone 5).
DeleteBut that's not how the "web apps" I'm talking about behave.
For fullscreen web apps created the way I describe above, the the full nitro JavaScript implementation is brought to bear (cf. http://appleinsider.com/articles/11/06/17/ios_5_supports_speedy_nitro_javascript_for_full_screen_web_apps.html). While you're stuck with the limited APIs provided by Apple (as I discuss above), at least your performance is not hobbled in the same way native apps' JavaScript usage is.
Ironically, this means that third-party iOS web browsers -- which are all just a thin layer of decoration around Apple's UIWebView -- could improve their performance five-fold by being rewritten as full-screen web apps themselves.
Adam, for a lot of thing you really need to use native apps. If you want access to sensors, for example, you pretty much need native (gps access is a pale imitation of real gps listeners, for example). That said, using UIWebviews in a hybrid app kind of way works pretty darn well. FWIW, I haven't seen a huge problem with performance, and I've even written an html5-style game. it's nice to hear that just turning on the jit would give a significant boost if apple ever cares.
ReplyDeleteYou might want to read my article about my experience writing Phresheez here http://rip-van-webble.blogspot.com/2012/01/call-me-rip-van-webble.html
Mike
Michael:
DeleteI'm curious about what aspects of the GPS interface you think are inadequate. Nokia has built a full-featured map application with it, including quite usable turn-by-turn directions (https://marketplace.firefox.com/app/here-maps-packaged). If you have some use in mind that requires even more GPS integration than is required to do that, I'd really love to hear about it.
Please run the Unreal Engine 3 demo on your Firefox phones before saying JavaScript does not have performance issues. Note that Epic Citadel was originally developed for iPhone 3GS in 2010 (3 years ago and for mobile!). From my PoV as a game developer it's a "very outdated experience".
ReplyDeleteAnd please see what's currently happening in the native world.
http://www.youtube.com/watch?v=8ZYkj0glnqs (PlayStation 3 native)
http://www.youtube.com/watch?v=UmkYHZpel3Y (iPhone native)
http://www.youtube.com/watch?v=3nJY7n8KaOY (Windows native)
AND DON'T CALL THESE YEASTERDY'S MODEL. A statement like that is very disgusting. IT'S TODAY. Many native developers are working hard and passionately FOR TODAY and make people happier.
I hope you Mozilla people will stop underestimating the effort of all native developers and make your web platform truly better first.
Thanks for your enthusiastic rebuttal.
DeleteIn my experience, once someone starts replying in all capitals, they are past the point of being interested in productive, civil dialog on a topic. Feel free to surprise me. However, you do raise a couple of points that may be of interest to other visitors, so I'm going to talk to them.
I originally thought you had a specific, concrete complaint to level at FirefoxOS's JavaScript performance. That's looking somewhat unlikely. The operating system load that the GeeksPhones shipped with (which was a developers preview, with all the performance penalties and other limitations implied by that moniker) doesn't actually have the technologies necessary to run the Unreal demo. You would have had to make your own FirefoxOS build to run the demo on one of those phones, and that's a bit of a tricky feat still. Until last Friday, the only way to even try to acquire an actual FirefoxOS phone -- with rare exception -- required physically traveling to Spain, Poland, Columbia, or Venezuela. I gather you're in Japan, which would make getting one of these from a carrier somewhat of an ordeal. I don't expect that the ZTE Open eBay orders would have been delivered already, but I guess it's possible. So, while I'm not saying it's impossible that you've tried out the demo, I do stand by my estimation that it's unlikely.
That said, there *are* a few caveats that will come with the initial FirefoxOS phones, and it's really only fair that they be pointed out honestly and clearly. The target demographic for these phones, at least at first, is those users who want something better than an old fashioned "feature phone," but find the price of smartphones a bit daunting. What this means is that the first FirefoxOS equipment on the market is going to be on some of the lowest-end hardware that can be produced efficiently today. That's why, even unsubsidized, you can get a ZTE Open for $80. For contrast, the cheapest unsubsidized iPhone 5 runs $650, or more than 8 times as much.
We nerds like our car analogies, so I'll throw one out there. Let's take this disparity and apply it to new cars. I'm going to use the Ford Focus as an example of a functional, economy-focused car. You can get one new for about $16,600. Now, if you were to consider FirefoxOS to occupy this functional, economy-focused niche, the iPhone of the car market would be whatever is about 8 times as expensive -- something in the neighborhood of $135,000. That would get you, for example, a nicely equipped Maserati GranTurismo. So, when you start making performance comparisons between FirefoxOS and the iPhone (or a Galaxy 4, if you prefer Android devices), you have to consider that what you're doing is equivalent to comparing a Ford Focus to a Maserati GranTurismo.
But not everyone can afford a Maserati GranTurismo, which is kind of the point.
Let's return to your specific example. I don't currently have a setup that I can run anything at full speed under FirefoxOS, since the only devices I have are running either the extremely slow debugging builds that I'm using to test WebRTC code or are running the stock GeeksPhone preview build, which isn't representative of the released operating system. If I'm wrong in my earlier assumption about your access to a real, non-developer-preview phone, I'd love for you to report back frame rates for the Citadel demo. You can get this by clicking on the loop at the top of the screen and selecting "Benchmark."
[continued in the next comment]
When I have some spare time, I'll put together a recent build of FirefoxOS with the code optimizations that ship on devices (not developer preview devices, but the phones actually sold as FirefoxOS devices), and see what kind of frame rate I get on the GeeksPhone Peak for this demo. Honestly, I am anticipating a perfectly watchable experience. As you point out, this really is demonstrating a rather old 3D engine. The reason I'm expecting it to be okay is that this particular port was performed using Emscripten, targeting asm.js. Performance testing of this combination has shown that the resulting scripts perform within a factor of two of native code. The iPhone 3GS -- which you point out ran this demo natively just fine -- had a 600 MHz ARM-based CPU. This Geeksphone has a 1.2 GHz ARM-based CPU. The math works out, and I do expect experience to follow.
Delete