
The Promise of Firefox OS - cornbread_bun
http://sergimansilla.com/blog/promise-of-ffos/
======
shadowmint
So... it's 2013, and I'm sitting here with my blazingly fast nexus 4, and the
web sites I visit are... slow. terrible. broken. spammy.

Half of them have 'popups' that try to banner at the bottom of the screen, but
end up flailing wilding and either taking up the entire screen, or just
helpfully sitting exactly over the middle of the page. A lot of them try
repeatedly to direct me to a specific page, or a native app when ever I flick
between pages.

The links are tiny and impossible to click on without zooming in.

It's just a terrible, terrible experience.

How do we get from this broken UX experience story of _right now_ , into the
magical compelling 'mobile web app' future that OP talks about?

I just don't see a roadmap for it. :(

~~~
bmuon
I worked as a front-end developer for an adnetwork for two years, so I take a
little responsibility for your experience. I tried my best, but there just
wasn't that much interest in getting it right.

Here's why I think we're all having a hard time with advertising in mobile.
Basically, adnetworks are still learning how to do it right, the same way
designers and developers are still learning how to do mobile websites right.
The layout issue you mention comes from a conjunction of various reasons:

* Marketing thinks mobile == iOS, which sets limited expectations and for example means developers have a hard time getting a variety of devices to test on

* Adnetworks are likely targeting mobile with the same front-end infrastructure they use for desktop. Most of them still target IE6 so they're trying the same ideas

* Old iOS versions and many other webkit browsers have big issues with fixed positioning. First they didn't support it. When they did, they still had issues rendering while scrolling and firing the correct events

* Ads in mobile require a complex layout but the standard in the industry is that the website doesn't have to do anything but insert a script tag in the page. If there was teamwork between websites and ads, they could use better layout tools like flexbox

* No adblock on mobile (yet?) :P

Hopefully it'll change.

~~~
cxhristian

      No adblock on mobile (yet?) :P
    

Rooted Android phones can install apps[0] that block most ads (I think it only
blocks connections to the ads and doesn't do any fancy CSS rules).

And Firefox on Android has Adblock Plus browser extension which as far as I
know blocks ads like it does on the desktop version. No root needed for this.

[0]: AdAway (I use this)
<https://play.google.com/store/apps/details?id=org.adaway>

Adblock Plus for Android (Seems to have some non-root support, I haven't tried
it):
[https://play.google.com/store/apps/details?id=org.adblockplu...](https://play.google.com/store/apps/details?id=org.adblockplus.android)

 _This app above is not the same as the browser extension mentioned before_

~~~
bergie
Firefox Mobile has Adblock Plus available.

~~~
cpeterso
Here's the link to Adblock Plus for Firefox on Android. It works great! :)

<https://addons.mozilla.org/en-US/android/addon/adblock-plus/>

------
anon1385
_And if your problem is with JavaScript as a language, you can already use a
myriad of languages that reliably compile to it. Do you come from a Java
background? You’ll probably like Dart, from Google. More of a functional kind
of developer? Try ClojureScript, which is an impressive, well-maintained and
well-performing implementation of Clojure on top of JavaScript. Coming from
Ruby? You’ll be almost at home with CoffeeScript. You get the picture._

God no. Instead of having to use a single awful language all the time I get to
choose what language to transpile to javascript and I never have to look at or
think about javascript at all. Unless of course there are bugs and then you
get to experience the pleasure of debugging machine generated javascript.
Maybe some people are filled with joy by the thought of debugging generated
js, all I can say is that those people are certifiably insane.

How about we work on platforms that support more that one language as first
class citizens. Is that really such a crazy idea in 2013?

~~~
hosay123
How does this differ from debugging any other VM? Except in Javascript you're
almost guaranteed your 'crash' will come as an exception with a stack trace –
guaranteeably raised by the only executing single thread that could contribute
state to the crash.

Debugging a Java or a C crash is infinitely worse, since instead of
comparatively pretty symbols and a verifiably correct trace, you have a vector
of bytes where your stack is supposed to be, and any number of threads running
third party libs that could have written all over your frame pointers, and
instead of semi-structured code you have a few thousand flattened basic
blocks, devoid of any type information, absolutely swamped in gotos and
boilerplate prologues/epilogues.

I'd much rather debug a JS exception than the subtle mental math required to
statically analyse the stack operations of some assembly.

~~~
anon1385
>Debugging a Java or a C crash in infinitely worse, since instead of
comparatively pretty symbols and a verifiably correct stack trace, you have a
vector of bytes where your stack is supposed to be, and any number of threads
running third party libs that could have written all over your frame pointers

My experience of crashes in C is that the OS typically provides a decent
backtrace including function names, not just a 'vector of bytes'. Your millage
may vary, I expect it depends what kind of C you are writing on what platform,
if you strip symbols etc. Sure your memory could get totally trashed beyond
recognition but that has not been very common in my experience. I'd like to
point out that I was not advocating writing C. I've not used Java but I always
assumed it gave you decent stack traces.

>instead of semi-structured code you have a few thousand flattened basic
blocks, devoid of any type information, absolutely swamped in gotos and
boilerplate prologues/epilogues.

I've honestly no idea what you are talking about here. Java code swamped in
gotos?

>I for one would much rather debug an exception in JS than the mental math
required in statically analysing the stack operations done by a chunk of
assembly.

If I'm writing Python I want a Python exception. If I'm writing Ruby I want a
Ruby exception. Not an exception from JS code that I did not write. I have no
idea what 'mental math' has got to do with this.

~~~
hosay123
On many architectures almost any stack overrun will overwrite the frame
pointer in C, resulting in a corrupted stack trace.

As mentioned in my second comment, I slightly conflated what C and JVM crashes
look like – the comparison was poor.

> I've honestly no idea what you are talking about here. Java code swamped in
> gotos?

Yes, the JVM has goto and your favourite compiler probably emits it, it's just
not exposed in Java. If we're to compare the similarity of debugging a crash
on the JVM to one on the "JSVM", then we cannot discount the complexity of the
toolchain producing the target JVM code. If we assume that toolchain is bug
free, then we must also assume a similar compiler targeting the JSVM is bug-
free. At which point the OP should not discuss trying to debug Javascript – in
this scenario it should never be required.

If instead we assume the JVM compiler and the JSVM compiler are not bug-free,
then we must account for the debuggability of their languages. In the JVM one
works in terms of stack offsets and goto (see
[http://en.wikipedia.org/wiki/Java_bytecode_instruction_listi...](http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings)
) while useful constructs like "string key -> Object map" are totally missing
(aka. a Javascript object), and all complex expressions are lowered to a long
series of basic instructions, all involving stack manipulation.

In contrast a JSVM-targeting compiler can emit human-readable expressions and
control structures, has no access to goto or stack manipulation instructions,
and short-term architectural choices about how those constructs are further
lowered is not baked into the language. Each individual implementation can
choose their own approach, and improve on it in the future without requiring
recompilation.

The result is that given a bad toolchain (and currently the JS transpilers
really are all quite bad, and JS lacks some trivial features like source
maps), the JSVM is an inherently more human-friendly debug target with less
assumptions about the runtime environment. By now it should be clear that to
compare you must discount the short term comparitive maturity of existing JVM
compilers – an excellent idea when making long term architecture decisions.
Additionally since in JS there are no threads contributing to shared state,
code flow is also easier to understand.

[Edit] If we're to discuss anything like supplanting Javascript as the
language for the web in the long term, let's not resort to 1980s architectural
notions about static, totally inaccessible binary formats. Approaches like
PyPy are far more interesting – given a minimally modified existing language,
annotate it such that an implementation can build an optimizing interpreter
for any language implemented in that existing language. Imagine Javascript
being that existing language, and suddenly all the upheaval and backwards
compatibility destruction disappears. Your JS-authored language interpreter
could still function in old browsers, it'd just execute more slowly.

~~~
anon1385
Maybe eventually we will have 'sufficiently smart transpilers' and interactive
debuggers for languages that target javascript and don't expose the 'JSVM' but
that is not the case at the moment. Mozilla said "And if your problem is with
JavaScript as a language, you can already use a myriad of languages that
reliably compile to it", i.e. if you don't like javascript you don't need to
use javascript. This is what I was responding to, because I don't see it being
true in the near future (next several years at least).

~~~
sanxiyn
Have you tried source maps?
[http://www.html5rocks.com/en/tutorials/developertools/source...](http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/)

~~~
anon1385
_Right now source mapping is only working between uncompressed/combined
JavaScript to compressed/uncombined JavaScript_

Which was exactly my point. The tools for targeting javascript from other
languages are non-existent at the moment, never mind mature enough that I
would want to rely on them in production.

As an aside, am I the only person who reads things like this and is filled
with a sense of foreboding:

 _The spec mentions cross site script inclusion issues that could arise from
the consumption of a source map. To mitigate this it's recommended that you
prepend the first line of your source map with ")]}" to deliberately
invalidate JavaScript so a syntax error will be thrown._

------
mephju
This is a real question and no trolling:

Why is nobody building a second kind of browser, one which is not based on
html and css. A browser which is geared towards app execution and development.
A browser which can run apps which can be programmed in a way that is similar
to programming Android apps. Where I can for example have a footer without
doing some css hacks. DNS and most of our backends could still be reused but
the client stuff would have to be written again. Delivering apps and linking
between them like the web does is awesome. Building sophisticated apps is not
awesome but on Android and iOS it is. Why not take the best of both
worlds...now....not in 10 years when some standards might agree on something.
Just think about how very important the web is. Everyone is using it. The
whole world largely depends on it, but it's increasingly not up to the task.
And why do web developers seem to be so satisfied with the state of the
technology which drives the web. Oh, you think css is great because you can
code a hack for putting a footer on the bottom of the page even when there is
no content in the attention area? What? It's so strange.

Why has nobody ever tried to create such a browser?

~~~
electrograv
I've thought about this a lot myself.

The language issue ultimately leads you to conclude that we need a browser
with a built-in VM, rather than a built-in scripting language. It makes _so_
much more sense, as a clean and elegant solution.

 _"I know! I'll make my own new browser with an embedded VM and newer cleaner
APIs, and revolutionize the web! It'll be amazing, allowing native-like
performance from the browser. WebGL will finally achieve performance feasible
for high quality games, the need for full native apps would be tremendously
diminished, etc. etc."_

JVM is a well known example of a cross-platform VM, which tried to enter the
browser via Applets. I think Java Applets failed because they were slow, ugly,
clunky, and usually looked horrible and disturbed the web experience. Kind of
like flash ads, but worse.

Microsoft Silverlight is kind of similar, but using the CLI rather than the
JVM. As a plugin, it still wasn't seamless. And it had cross platform
compatibility issues (not a fault of the CLI though).

The GUI issue (bloated DOM, hacky HTML/CSS) leads me to conclude that we need
a new API stack for rendering GUIs that satisfies both web and application use
cases without massively sacrificing memory and performance like the DOM seems
to excel at.

But here's the thing:

Creating a new browser with a new VM and new GUI stack, all from scratch, is
almost an insane undertaking. Sure, it's one I could almost see myself trying
(being a perfectionist ADHD OCD coder) as a hobby, but I know better than that
if I want to actually ship anything.

Ideally, I'd like to see some day a kind of "Mono Browser" - a browser that
basically runs CLI code "scripts" in an otherwise traditional HTML/CSS stack
for backwards compatibility. But the primary feature would be a new GUI stack
completely disjoint from HTML/CSS for people who want to create blazingly fast
and native-like snappy UIs.

It's fairly critical though to expose this new GUI stack, because otherwise
it's just CLI-scripting-in-the-browser. CLI in a regular browser would be
great IMO, but not a significant enough change for end-users to upgrade to the
browser. Moreover, such a API stack would be extremely useful for cross-
platform developers even of native apps. It would essentially compete with
web-based cross platform frameworks like PhoneGap, and native ones like QT
(though QT IMO is ugly and old fashioned vs web rendering).

So a great deal of work lies ahead in creating this GUI stack. This is
something I'm kind of intermittently working on in my spare time.
Unfortunately I'm usually kept quite busy on research work towards a PHD, but
now and then I make a little progress. But if you know of others working on
something similar, feel free to point me in that direction to collaborate.

~~~
ux-app
I've also been thinking about the same sorts of things lately.

Mostly I've been thinking about the GUI issue on the web. CSS and the DOM are
just not up to the task of creating a responsive app GUI. The incredibly
complex set of nested CSS rules that need to be calculated and applied for
each reflow is a nightmare.

I personally think the DOM is a fine way to define an app structure. GUIs are
after all containers and components which map nicely to nodes in a tree.

CSS is great for presentation (colors, font styles etc). One of its strengths
is its simplicity and its cascading nature.

What we need is a sane constraints-based layout model. This is standard fare
for native apps (eg: iOS autolayout).

Imagine being able to specify:

    
    
      Block_A sits at the top of the window.
      Block_B is anchored to the bottom edge of Block_A.
      Block_C is inside of Block_B and is anchored to the left edge.
      etc..
    

A complex layout can be defined in a handful of rules which even JS can solve
for.

Solvers for these types of optimization problems have been around for 20+
years. There's even a nice one written in JS eg:

    
    
      http://www.badros.com/greg/cassowary/js/quaddemo.html

~~~
nsm
I've often wondered about replacing HTML/CSS/JS with QtQuick and QML.
Thoughts?

~~~
ux-app
I don't have any experience with Qt&QML, though I've heard lots of good things
about it.

I don't think a wholesale replacement of HTML/CSS is feasible though. There's
just too much inertia behind the incumbents, not to mention that HTML/CSS is
very good for the document centric web which applies to 90%+ of the existing
web.

More flexible CSS layout modes such as display:flex are quite usable and go
some of the way to addressing app-style layouts, however movement on these
standards is slow and doesn't go far enough IMO.

------
soapdog
Some people on this thread are completely missing the point of Firefox OS.

Its about standards and making it work cross-platform with no lock-in about
vendors. Last week, I spent some days on a hackathon to promote Firefox OS app
development. It was very refreshing and fun.

After developing for iOS and Android, developing for a mobile phone using JS
was a very good experience. I enjoy using Javascript. I think Obj-C is great
too and I am not fond of Java but this is not about whats your favorite
language, its about bringing the freedom of the web to your mobile device.

In couple days, I created a tiny QR Decoder that anyone with a Firefox OS
device could browse too and install on their phone. That was great. During the
hackathon we shared lots of apps between each other without the need for
market approval, vendor saying or whatever. And yet there's the Firefox
Marketplace to help discovery and certification for privileged apps.

Firefox Aurora for Android already has open web apps support that allow you to
install web apps on your Android device and will hopefully implement all the
WebAPI. Once Android and Firefox OS support the WebAPI there will be pressure
on the other vendors to implement it as well and then we'll be in a better
place than we are now.

------
robotmay
I'm really excited for Firefox OS, but I'm not sure why. Maybe it's because I
have a lot of respect for Mozilla and the high quality of their software.
Having a fresh ecosystem is always going to attract developers who haven't
bothered with the current platforms due to overcrowding (among other things),
even if it never rivals the size of Android/iOS.

------
DrinkWater
Some people are not getting the main goal of the Firefox OS: To give emerging
markets (cheap) smartphones and keep the web as open as possible. Therefore,
HTML/CSS/JS is a damn good combo to keep the web open, and to enable rapid
development of apps.

------
lifeisstillgood
Glad to see this coming out - I think the technical chutzpah of FirefoxOS is
fantastic, now let's see Mozilla Market it in the same clear vision and
spirit.

I mean I simply did not know there was an emulator
([https://hacks.mozilla.org/2012/12/firefox-os-
simulator-1-0-i...](https://hacks.mozilla.org/2012/12/firefox-os-
simulator-1-0-is-here/)) until this post, and honestly I looked.

Edit: oh and can someone tell me if persona is taking off or not - are there
stats from login.persona.org?

~~~
stomlinson
Hi lifeisstillgood, I am one of the core Persona developers. Persona is a
pretty awesome project with very ambitious goals. We obviously want to see
growth explode and are working hard to make Persona great for both users and
site operators.

Persona's growth has been steady, primarily driven by newly developed sites.
We hope that as the user base grows and support for the BrowserID protocol is
natively built into the browsers, existing sites will have more of an impetus
to offer support.

A version of Persona is already integrated into FirefoxOS and we hope to offer
support in desktop Firefox by the end of the year.

If you want to participate in discussions, have an idea on how we can improve,
or just want to see what we are up to, our mailing list is open to everyone:
<https://groups.google.com/forum/#!forum/mozilla.dev.identity>

~~~
lifeisstillgood
Thank you - I have just joined the group.

I agree - Persona is an awesome project - and I like anything that is going to
take the pain of managing passwords away from me.

I am most interested in python / wsgi integration - if any of your collegues
are working on this I will be very happy to contribute.

~~~
minikomi
In some downtime at work I threw together a rough proof of concept just to see
what it invloves in go[1].. It was crazy simple to get running. I hope people
start using it in more places.

[1] <https://gist.github.com/minikomi/4563344>

------
supercoder
I'm starting to feel like html/js/css is starting to become the 'this will be
the year of linux on the desktop' of apps.

They're flexible technologies, but don't think they'll ever have the feel of
purpose built native API's.

~~~
PommeDeTerre
Only just starting? It was pretty apparent after the DHTML craze of the late
1990s fell flat on its face that web apps weren't any threat to native desktop
apps. Then the exact same thing happened during the mid 2000s, when AJAX was
all the rage. The more recent HTML5/CSS3/JavaScript fad is yet one more
revival of the same failed set of ideas.

~~~
Offler
I think those eras had browsers that weren't capable of delivering on the
promise.

If you only work with IE9+ (all the other browsers are quite good now) you
will be working in a run time environment that is far superior to those
available in the DHTML/Ajax era.

Another issue is that very few people know how to do large scale JS
applications, where I work we do (130,000K+ lines of code, 900+ classes) but
it has taken us several iterations to get to this stage.

I believe we are planning on making our tools open-source so hopefully people
will start to see that large scale JS apps are very doable. www.caplin.com if
you want to keep an eye on the open sourcing of our tooling.

~~~
chris_wot
900+ classes, in Javascript?

~~~
Offler
We have a framework more than a library, we basically ship a framework that
our clients use to create their own web trading applications. This framework
covers many asset classes and many use cases.

It's not likely that any client would use all of our code and so we have build
a tool framework that only pulls in the JS code that your application uses,
this is done without a build and is immediately available (add a 'new
namespace.sub.Class()' line and hit f5 and it will be in the js bundle you
get.)

We bundle js, css, xml, i18n tokens etc.

All automatic and requiring no build.

------
janjongboom
Good article. The main reason for FFOS is not to take over the world but
rather disrupt the closed ecosystems that Google, Apple and Microsoft are
creating; the same way that Firefox broke Microsofts monopoly on the browser
market.

~~~
lucian1900
Except Android is no more or less closed than Firefox OS. Both open source,
allow sideloading and have curated app stores.

~~~
janjongboom
Android itself isn't, but the ecosystem that they're building is. The market
is controlled by Google and the apps will only run on Android phones. Not the
OS is important, the ecosystem is. That's why Apple and Google and everyone
are trying to keep everyone inside.

~~~
lucian1900
The Firefox OS app market is controlled by Mozilla and the apps will only run
on Firefox OS (for now, at least).

Everyone is free to implement the Android app API, as Blackberry have, just
like they are free to implement the Firefox OS phone APIs.

The difference is very small. Firefox is more likely to have portable apps,
Android offers a much higher quality API for building apps.

~~~
kibwen

      > The Firefox OS app market is controlled by Mozilla
    

One clarification here: Mozilla's marketplace code is entirely public (though
confusingly named):

<https://github.com/mozilla/zamboni>

Any corporate or individual entity could take this code and set up their own
entirely compatible platform.

~~~
lucian1900
While the Play backend isn't open-source, there are already at least two other
competing app stores.

The differences really aren't that big.

------
mikecane
I still don't understand why Firefox OS will go anywhere when webOS did not.
Aren't we talking about basically the same thing? HTML5/JS/CSS? Is it timing,
the changed environment that now focuses attention on web apps? Is it the
reputation of Mozilla vs that of Palm/HP? I'm not saying web apps won't have a
place, I'm just extremely confused about the seeming contradiction or about-
face here.

~~~
chris_wot
Palm/HP didn't exactly make it a huge deal to go to standards bodies, did
they? That was my impression. Could be wrong.

~~~
mikecane
Yes, perhaps that's it. The mention of standards bodies stood out to me too.

------
Uchikoma
I've read the article, I agree with the HTML5/JS premise, but I still do not
understand Firefox OS.

------
logn
I can easily see it beating Android/iPhone (or at least competing). I can't
wait to get my hands on such a phone and I'll definitely be making apps for
it. I think a lot of developers are like myself since 1) it's all
JavaScript/HTML5 which is cool and 2) it's by Mozilla and company. Once there
are a bunch of apps the people will come, unless the mobile industry decides
to make this fail or Firefox OS turns out to be terrible.

Also I think people miss, this isn't just a phone full of webapps, it's about
opening up the native functionality of the phone to JavaScript. So operating
the camera, accelerometer, contacts list API, etc.

------
erikj54
Interesting if this is in fact the goal. I would argue you still will have a
mix of both. No ubiquitous environment, but Web apps will get first class
support on upcoming platforms. At least this seems to be the most logical
route. If you've ever used Cordova or "PhoneGap" you would know about the plug
in architecture and how it is in fact still the wild west. Developers write
native extensions to do things the underlying JS API can't, this won't change
for a long time until the Web API does. The future is a mix of both Web and
native, not just the Web.

------
VaucGiaps
I would have liked to have heard a story like this one at FOSDEM. You had a
room full of interested IT people/devs/... and missed selling the 'spirit' of
fOS. Too bad...

~~~
pragmatictester
<https://fosdem.org/2013/schedule/event/firefox_os/>
<https://fosdem.org/2013/interviews/2013-jonas-sicking/>
[https://fosdem.org/2013/schedule/event/automating_firefox_os...](https://fosdem.org/2013/schedule/event/automating_firefox_os/)

------
jpwagner
There are plenty of js/html frameworks for mobile. That mission was (and is??)
the _promise_ of webOS. So I don't see how you can say "even in the unlikely
event that Firefox OS itself disappears in the process, if web-apps become
mainstream it will have succeeded" since it's far from a controlled
experiment.

Mozilla always seems to have the same answer to "what if we just started from
scratch": which is "let's do it". It's endearing I guess.

~~~
bergie
One big difference here is that Firefox OS (just like PhoneGap/Cordova) is
aiming at standardizing the APIs, not at just being _another framework_.

That by itself will make the web richer regardless of how FFOS fares on the
market.

~~~
zokier
And what makes those "standards" different from "another framework"? A rubber
stamp from W3C?

~~~
bergie
Yeah, and usually a compliance test suite. And nowadays browser vendors even
seem to be quite active in implementing these things.

See for instance [http://blog.chromium.org/2013/02/hello-firefox-this-is-
chrom...](http://blog.chromium.org/2013/02/hello-firefox-this-is-chrome-
calling.html) and [https://hacks.mozilla.org/2013/02/hello-chrome-its-
firefox-c...](https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-
calling/)

In general, I'm curious about the hatred here on HN towards W3C. Sure,
standards often move slowly, but it is still the best way to achieve
interoperability.

------
itsbits
Good...i would be interested to know what kind of hardware support FireFoxOS
would be targeted to build on...Just you know before i buy my new mobile......
I am already looking fwd for UbuntuOS which also supports JS as native and
Nexus seems to fill their hardware req.

------
brudgers
In the abstract FireFox OS is appealing.

But the likely realities aren't. It's hard not to assume the ease with which
Firefox the browser can be installed by my Mom when thinking about the OS. But
doing so is plain wrong.

For most end users it will be as tied to a particular device by the
manufacturer as any other mobile OS. And the likelihood that the end user
will, as a practical matter, be able to load Firefox OS on their own is low
because there is no ISA for mobile and the mobile ecosystem is so mined with
patents.

It's not that some people may not be able to hack Firefox OS onto an iPhone -
I actually expect it. It's that such hacks will kludged beyond utility for
most non-technical people.

~~~
TazeTSchnitzel
You're missing the point of Firefox OS. They don't want to make an OS, they
want to make the web a good platform for apps.

------
kunai
Interesting. I'd love to see Firebooks in the future along with Chromebooks.
It would be nice to have two cloud-based operating systems for the desktop out
there.

------
Apocryphon
"But how is it going to beat Android or iOS?”

I'm more interested in how it stacks against other open source mobile OS's,
most importantly Ubuntu, but also open webOS and Tizen.

------
kiba
Can FirefoxOS run on top of android or iOS, or is that lower level?

~~~
sergimansilla
The applications can, through Firefox for Android. That means that if you use
WebAPIs that access phone internals, it will work just fine.

------
camus
At the end of the day , the only user will care about is the app store and
performances. If the apps are great and run fast then people will not care how
they are made. That's the only thing we should care about.If FFos doesnt
deliver on these levels then it wont work. There is already an os for cheap
celphones , android. Cheaper hardware means crappy software.

------
cmccabe
If the stench of doom were any stronger on this project, Id Software would
have to sue for trademark infringement.

