Your argument is quite plausible. Android has indeed accumulated several APIs: ANSI C, POSIX, various Khronos APIs (OpenGL ES, OpenMAX), a subset of J2SE, and Android APIs (both Java and native, with some overlap between the two). I can accept that offering only web APIs leaves much more room for streamlining the lower layers of the stack. Maybe a future Firefox OS phone will run a new processor that was specifically designed to execute JavaScript.
And perhaps my earlier point about HTML+CSS and web layout engines being designed for documents, not UIs, was too handwavy. One might argue that there is a sort of Greenspun's tenth rule of UI toolkits: Any sufficiently complex UI toolkit contains an ad hoc, informally specified, bug-ridden, slow implementation of half of HTML and CSS -- and then probably contains a full Web browsing engine, too.
It seems to me that the Web technology stack has plenty of inelegance of its own. But no platform is perfect. Maybe the Web platform, exposed to developers on its own without making the lower layers available, really is the best we've got.
Can you explain why you think the Java storage APIs are ill-suited to mobile devices?
> Maybe a future Firefox OS phone will run a new processor that was specifically designed to execute JavaScript.
I haven't heard of any such plans, but that would be fun. Ah, the good (?) old days of the Lisp machine...
> Any sufficiently complex UI toolkit contains an ad hoc, informally specified, bug-ridden, slow implementation of half of HTML and CSS -- and then probably contains a full Web browsing engine, too.
Let it be said that the Mwcampbell Law was first enunciated on Hacker News on the Ninth of July, 2013.
> Can you explain why you think the Java storage APIs are ill-suited to mobile devices?
Generally, it's a set of simple things. The File API, for instance, should forbid execution of any I/O call on the UI thread, or on any high-priority thread, as the duration of any I/O call is unbounded (Dalvik can be executed in a "strict mode" that prevents I/O calls on the UI thread, which is good, unfortunately that's not the default mode).
Also, the default manner of doing any copy with the File API is a read/write loop, which is very inefficient in terms of memory copies, especially when Linux offers in-kernel copy.
No, they are not plausible. The whole idea of using HTML, CSS, and JavaScript as the back end technology for a low-end smartphone is nuts. Even the best HTML rendering engines are CPU and memory hogs. CSS was never designed for and is nearly impossible to hardware accelerate, and JavaScript is notoriously difficult to optimize and even the best VMs run orders 3-10x slower than native code, while the JS VM takes up much more memory than the efficient dalvik.
All the early reviews of Firefox OS describe it as laggy and slow. For example this one from the verge:
"Lag is a major concern — apps took multiple seconds to load, to change toggles, and to make UI transitions"[1]
Or this one from CNET:
"unresponsive screen makes typing a laborious process requiring painstaking precision. Every action from swiping to tapping onscreen controls takes a beat until you see results, so using the phone for a prolonged period steals minutes of your time... Lag carries into the camera, which is slow to launch, snap, and reset."[2]
>"designed for documents, not UIs, was too handwavy" Not for anyone who's had to work with DOM for Web apps. We know all too well as its name suggests that it was never designed for apps and is well past its expiration date.
My 3yr old similarly spec'd SGS runs CM 10, Jellybean like a champ. My mom's worse spec'd 3GS is still smooth and fluid. Of course, a low end Android phone running the most resource intensive skin, TouchWiz, is going to perform poorly, but in my experience vanilla AOSP scales down quite nicely on low-end hardware.
So how does this phone benefit Joe User? It's an android kernel, but the user is cut off of the diverse android app ecosystem. The performance looks terrible, and the user is locked into the Firefox browser, like Safari on iOS.
That's not all that surprising. IPhone 3GS and Samsung Galasy X had launch prices four to five times higher than the phones you are talking about. Of course they are faster, the same way that old BMW M5 is faster than new Ford Fiesta.
But that's not the point. FFOS can't really offer that much to rich people in US or Western Europe where iPhones grow on trees and streets are paved with high-end Android phones. It is not supposed to compete with the next iPhone or Nexus, but with the next Nokia Asha, cheap Bada phone or the next cheap ZTE, Alcatel or Huawei Android phone that is still sold with Android 2.3.
I'm guilty of handwavy explanation, so I will try and get back to concrete cases.
The reviews by CNet and The Verge were accurate a long time ago – given the date, CNet's review was done with an early beta, and I have no clue about the date at which The Verge's review was done, but I suspect that the review was published long after the actual review. I have seen the speed of my phone increase considerably since then, both when I was running 1.0.x and now that I'm running 1.1.x.
If you want to know for yourself the actual performance of a FirefoxOS phone, the only way is certainly to get your hands on one. My personal experience is that, comparing with equivalently-spec'd unmodified Android phones, my FirefoxOS phone runs absolutely great. I have not attempted to compare with Cyanogen-ed phones.
> The user is locked into the Firefox browser, like Safari on iOS.
Actually, with effort, it should be possible to port WebKit/KHTML or any other rendering engine to FirefoxOS, e.g. by using Emscripten or Mandreel. Of course, this port will have to use the platform's display API (typically, Gecko's implementation of <canvas>) and the platform's VM, so the benefit might be limited. But if somebody considers this useful or fun, please, by all means, do port any other browser to FirefoxOS, we will be glad to help you.
That's not quite the answer you would get from Apple if you wanted to port Firefox or old-generation Opera Mobile (not Turbo) to iOS.
> So how does this phone benefit Joe User? It's an android kernel, but the user is cut off of the diverse android app ecosystem.
Several comments have already provided an answer to that question. I will try and sum up a few of them quickly:
- all your private data doesn't belong by default to some company;
- the Mozilla community has proved time and time again how it is able to provide applications localized for regions/minorities that big companies simply ignore, and I expect that this will also be the case for FirefoxOS phones;
- payment APIs implementations are adapted to local markets, i.e. in countries where people typically don't have a credit card, they do not have to use one if they wish to buy an application;
- users are even more free from the Marketplace than on Android - I expect that this means we'll soon see numerous marketplaces specialized in local interests (e.g. Venezuelian marketplaces, Catalan marketplaces, but also a company's internal marketplace, etc.), or in application domains (e.g. Gaming, e-books, adult stuff, safe-for-kids stuff, etc.);
- cheaper phones through higher-performance on entry-level hardware – recall that, in Spain, the phone is sold at 69€ including 30€ prepaid communications, without contract;
- no vendor lock-in – if you change phone or if you use your desktop computer, your applications follow you;
- breaking monopolies in regions in which you have the choice between a feature phone or a 600$ smartphone + contract.
I realize that people following Hacker News are no Joe Users and that they often have access to technologies that Joe User hasn't even heard about, both in terms of hardware and in terms of software (e.g. Cyanogen). But this first generation of FirefoxOS phones is not designed with them in mind. It is designed primarily for Joe "I'm ignored because my region or my language is not fashionable or rich enough" User.
And perhaps my earlier point about HTML+CSS and web layout engines being designed for documents, not UIs, was too handwavy. One might argue that there is a sort of Greenspun's tenth rule of UI toolkits: Any sufficiently complex UI toolkit contains an ad hoc, informally specified, bug-ridden, slow implementation of half of HTML and CSS -- and then probably contains a full Web browsing engine, too.
It seems to me that the Web technology stack has plenty of inelegance of its own. But no platform is perfect. Maybe the Web platform, exposed to developers on its own without making the lower layers available, really is the best we've got.
Can you explain why you think the Java storage APIs are ill-suited to mobile devices?