
Why I care about Firefox OS fading away - SunboX
https://gist.github.com/SunboX/1fb5a3ebc520e4facf47
======
benlower
IMO the bigger reason to lament the loss of competition here is the app model:
Firefox OS was pushing for "apps" to be web apps. That seemed a lot more open
to me than pushing for apps to be proprietary (Android, iOS, Windows, etc.).
As great as mobile devices are, their walled gardens stifle creativity,
privacy, and choice.

~~~
Sanddancer
Apple was pushing for "apps" to be web apps when they first released the
iPhone as well [1], with Steve Jobs going as far as to say that native apps
would potentially "damage the phone system". It wasn't until after the iphone
was jailbroken, and people kept insisting on more powerful development choices
that they started on their app store. People have been saying that webapps are
the future for a decade now. At this point, I have to say it's never going to
happen.

[1] [http://www.apple.com/pr/library/2007/06/11iPhone-to-
Support-...](http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-
Third-Party-Web-2-0-Applications.html)

~~~
kitsunesoba
I think that one day, web apps by default could work, but before that can
happen the web must see sweeping change.

The lackluster performance and high resource usage associated with web apps is
a direct consequence of the complex patchwork nature of each component
involved. Quite simply, the web was not designed to be used the way we’re
using it, and evolving standards have made browser rendering engines
horrifically complex (and in some cases convoluted).

What’s needed is a fundamental reimagining of HTML, CSS, and the DOM at
minimum with little to no regard for legacy. In the 90s, we didn’t know what
we needed but now the picture is crystal clear. Should we use this knowledge
to design a new web, I’m positive that the result would be just as open as the
web is now while performing tens or hundreds of times better — it’d likely be
good enough to make web apps competitive with native apps under a far wider
set of circumstances.

~~~
pcwalton
You'll have to explain why in details, not at a high level. In particular the
fact that a replacement could perform "tens or hundreds of times better" is an
extraordinary claim.

CSS has tons of problems, but almost every replacement for CSS that I've seen
proposed would almost certainly have worse performance characteristics than
CSS, optimally implemented, would. Most of them kill parallelism and kill
opportunities for optimal GPU usage—they're proposed cures that are worse than
the disease. The problem is mostly that browsers don't implement CSS as well
as they could due to legacy, not that the technologies are fundamentally
flawed (though this is not to say that they're not improvable, far from it).

To create a better architecture, you first need to have an in-depth
understanding of what the problems in CSS actually are. Otherwise, you'll just
trade one set of mistakes for another. (In particular, a CSS replacement that
optimizes for Web developer productivity will _not_ necessarily have
acceptable performance characteristics—too often, people assume that "easy to
develop in" implies "runs fast", which in fact these concerns are often in
direct opposition.)

~~~
ben0x539
can't wait for servo "strict mode" css!!

------
Analemma_
I don't want to sound like the know-it-all smartass here, but from the moment
Firefox OS was announced I gave it a negligible probably of amounting to
anything and was really baffled that Mozilla decided to focus their efforts in
that direction.

I don't think they appreciated just how brutal and unforgiving the smartphone
market is. Apple makes money on it, but they spend billions on R&D and
billions more on marketing. Samsung makes money, but a lot less than they used
to and only because they own their entire component pipeline and _also_ spend
billions on marketing. Google makes money, because they own the operating
system that 80% of the phones use and use it to push people to their wide
array of services. Everyone else is breaking even at best, and hemorrhaging
cash at worst. Think how many billions Sony and Microsoft and Nokia and Palm
and Blackberry spent on their smartphone efforts only to get shoved to the
sidelines. This is a market where you've gotta pay _big_ in order to play; to
be honest it was downright silly of Mozilla to expect that they could get a
foot in the door.

~~~
AnthonyMouse
Isn't this basically the same argument as that Debian can't make any inroad
into servers because IBM and Microsoft spend untold sums on R&D and marketing?

What has been killing Firefox OS (and nearly everything else Mozilla does
outside of Firefox) is their peculiar abhorrence for _anybody else_ writing
anything in native code.

~~~
fabrice_d
No, what is making or killing a mobile OS is whether some key apps are
available or not. Many people don't really mind using an OS or the other, but
they absolutely need eg. WhatsApp. The unwillingness or WhatsApp to write a
mobile web app - or to let a 3rd party do it - made more damages to FirefoxOS
than anything else writing in the comments so far.

~~~
AnthonyMouse
But that's true of any platform ever. You need third party developers to
either target your platform or a platform your platform is compatible with
(like the JVM).

Mozilla wants to use the web as that platform _exclusively_ , which is fine if
everybody is _already_ making everything for the web _and_ there is nothing of
importance you can do with native code that you can't do from the web. But
neither of those is true so their strategy fails.

~~~
pcwalton
> Mozilla wants to use the web as that platform exclusively, which is fine if
> everybody is already making everything for the web and there is nothing of
> importance you can do with native code that you can't do from the web. But
> neither of those is true so their strategy fails.

There are things you can do on iOS that you can't do on Android (e.g. Apple
Pay), and vice versa (e.g. Google Now). iOS fails the "there is nothing of
importance you can do on Android that you can't do on iOS" test, and Android
fails the "there is nothing of importance you can do on iOS that you can't do
on Android" test. Yet here we are, with two successful platforms.

I think the truth is a lot more nuanced, and in particular I think the
emphasis on "native code" is a convenient red herring. (Android isn't really
native code for anything but games, and iOS Objective-C is technically native
code, but that Smalltalky object system is not up to C++-level performance, so
the distinction doesn't mean much.)

~~~
AnthonyMouse
> iOS fails the "there is nothing of importance you can do on Android that you
> can't do on iOS" test, and Android fails the "there is nothing of importance
> you can do on iOS that you can't do on Android" test. Yet here we are, with
> two successful platforms.

At which point you have to ask whether the missing things are actually that
important.

> I think the truth is a lot more nuanced, and in particular I think the
> emphasis on "native code" is a convenient red herring.

"Native code" in this context is as distinguished from aggressively sandboxed
javascript received over the network in real-time. It's not only about
performance. It's about the app still working where there is no wireless
signal, or being able to read or write device-wide settings or files, or make
a VPN work, etc.

~~~
pcwalton
> At which point you have to ask whether the missing things are actually that
> important.

Right. And the choice of programming language isn't.

> "Native code" in this context is as distinguished from aggressively
> sandboxed javascript received over the network in real-time... It's about
> the app still working where there is no wireless signal, or being able to
> read or write device-wide settings or files, or make a VPN work, etc.

Firefox OS had all of those capabilities (maybe excluding VPN depending on
your definition--but if your definition of "making a VPN work" excludes
Firefox OS it excludes iOS apps too). Firefox OS was based on locally
installed apps.

~~~
AnthonyMouse
> Right. And the choice of programming language isn't.

The platform isn't just the language.

> Firefox OS was based on locally installed apps.

Then I have no idea what we're talking about.

So the point of Firefox OS was supposed to be what, you make the UI using HTML
and javascript but then it runs locally and exposes system call wrappers
through javascript?

That's not actually so bad of a concept, but then you have the opposite
problem. Nothing that does anything you can't do in a traditional web page is
portable outside of Firefox OS so you have no user base to attract developers.

It seems like they're trying to compete with _Android_ when they should be
trying to compete with _Java_. Make a runtime that runs the Firefox OS apps on
Debian and Android and Windows. That would be interesting.

~~~
pcwalton
> That's not actually so bad of a concept, but then you have the opposite
> problem. Nothing that does anything you can't do in a traditional web page
> is portable outside of Firefox OS so you have no user base with which to
> attract developers.

Yes, I'd agree that is/was much more of a problem than the technology stack
itself.

> Make a runtime that runs the Firefox OS apps on Debian and Android and
> Windows. That would be interesting.

There is such a thing: [https://developer.mozilla.org/en-
US/Marketplace/Options/Open...](https://developer.mozilla.org/en-
US/Marketplace/Options/Open_web_apps_for_desktop)

------
Sanddancer
The death of FirefoxOS was inevitable, because of two words that the
supporters dread. Native Apps. If your problem did not match the things that
Javascript was good at, you were completely out of luck. Every other platform
has a way of writing your app in different languages. The iphone has native
swift and cocoa, plus javascript, plus lua, plus a whole host of other
choices. Android has java, javascript, and anything else that can be run via
jni. Windows has WinRT, which doesn't offer native code, but does offer
anything that can be run under the CLR -- C++, C#, Javascript, etc. Firefox
OS's sticking with just javascript meant that it was hamstrung from the start,
with much less ability to create apps that really stood out, leaving it to
wallow in mediocrity.

~~~
pcwalton
There aren't any substantive differences between the CLR and the minified
JS+asm.js model (or, even more so, the minified JS+Web Assembly model).

There _are_ differences, but they're details. CLR IL is quite high level.

In general, I feel people oversimplify the "Web vs. native" performance debate
to differences in programming languages, because programming languages are
easy to tell apart (unlike for example rendering stacks) and it's easy to
benchmark them. But I probably wouldn't even put the JS vs. Obj-C or JS vs.
Java dichotomy in the top 5 reasons for any performance difference.

~~~
Sanddancer
There are rather substantive differences. For starters, the CLR doesn't have
to be the IL anymore; since Roslyn and the WinRT framework, you can compile
down to native code. However, the most important things are what the CLR gives
to the developer that Javascript doesn't.

Syntax-wise, the CLR's threading is much more flexible -- you can have your
workers talk to each other directly when that's the most convenient way of
doing things, instead of the Web Workers model where everything has to pass
through the main thread. The CLR also supports more than two number types,
which is useful in a number of situations, such as art programs, where most if
not all of your actions are going to be against smaller types. Web Assembly
fixes some of these problems, like providing reasonable number types, but at
the same time, ignores other flaws that still exist, like a lack of vector
types, which is something nearly every modern processor has and uses for
improved performance.

The problem with Javascript, and its various extensions and adjuncts is that
it still suffers from the same walled-off mindset that it has for the past
fifteen years. Numbers are numbers and you're crazy if you want anything other
than these beautiful 64 bit floats, a compact, easy to parse bytecode format
is an affront to the open web, even if the alternative is a hack that is just
as unreadable, and threading will just lead to programs crashing. Javascript
may be fine if you're delivering a web page, but the tools it gives make it
woefully unusable for near anything else.

~~~
pcwalton
Nope. asm.js as implemented in Firefox supports native integers and SIMD.
SharedArrayBuffer gives you threads--but honestly this is a red herring, with
apps barely making any use of multicore and iPhones being limited to 2 cores
anyway. Web Assembly gives you 64 bit ints.

"Compact, easy to parse bytecode" is also irrelevant. JS is easy to parse. And
the parser is such a tiny part of a JS engine it doesn't matter at all in
practice for complexity. It's an aesthetic concern.

The actual performance problems Web apps hit have nothing at all to do with
any of the areas you describe anyway. You think the Facebook app is making
heavy use of custom SIMD or multicore? The SIMD support in Firefox gets barely
any use because apps can't find a use for it. Apple isn't adding cores to
their phones because apps aren't using them. And so on.

~~~
teacup50
Apps barely making use of multicore? Maybe in your web world.

We would not have been able to ship the apps we've shipped were it not for
being able to exploit shared state concurrency.

... and yes, I think the Facebook app is making heavy use of multicore and
SIMD; multicore directly, and SIMD by way of the heavily optimized native
frameworks shipped with the device.

I've previously made of NEON to get ideal performance out of critical path
file decoding on lower end devices, where having those additional CPU cycles
available made the difference between stuttering and smooth UI.

Stop trying to fit native apps into a box you've defined to match your web-
centric experience, where low expectations are simply the norm.

~~~
pcwalton
If apps were using multicore all over the place, the hardware vendors would
have responded by increasing the number of cores on the CPU as they planned
to. Instead, they didn't, because people aren't using it.

I don't see any particular use the Facebook app would possibly have for
multicore. Image and video decoding perhaps, but browsers already multithread
those.

The point about native frameworks making use of SIMD applies equally to the
SIMD that the browser engine components internally use.

Finally, I've been writing native code almost exclusively for the past five
years.

~~~
nodamage
In this context threading is less about making maximum use of multiple cores
and more about "never blocking the main/UI thread". Even on a single core
device you usually need to start offloading heavy computation to a background
thread to keep the UI responsive.

Even today I'll run into websites that lock up a browser tab because they're
running a whole mess of Javascript soup (typically jQuery). I know we were
promised WebWorkers like 5 years ago but does anyone actually use them?

~~~
pcwalton
Yes, I fully agree that this is one of the biggest problems. Web developers
don't treat Web Workers like they treat Blocks in Objective-C, and this is
causing performance problems. On the engine side, we have to figure out how to
make workers and off-main-thread work just as easy to use as in Objective-C
and Java--I believe this is doable with effort.

------
boondaburrah
My main problem with all these "well, it failed" alternative operating systems
for phones are: I couldn't even buy them in the first place. I tried, but
there was no hardware available in my region that ran on my network etc. The
closest thing we've got is the nexus, but what we need is a 'standard' (de-
facto or otherwise) phone like x86 PCs had to be in order for linux to take
off.

~~~
denniskane
>in order for linux to take off

We need Linux on the Web!

[https://linuxontheweb.appspot.com](https://linuxontheweb.appspot.com)

~~~
comex
That isn't Linux.

------
seba_dos1
I don't really care. And that makes me sad.

I was really excited about Firefox OS when Mozilla was announcing it. I've
been playing for years with free smartphones like Neo Freerunner, GTA04 and
(surprisingly free) Nokia N900, and the situation on Android market was far
from being good for me. I still cannot really change my phone without
downgrading my user experience. Firefox OS offered me some hope.

Unfortunately, it turned out that Firefox OS was just Android-me-too, without
much of added benefits when it comes to user freedom. Sure, the development
model was more like baazar than cathedral, but how did it matter if most of
the Firefox OS devices out there were as blocked and closed as Android ones?

Mozilla even had a certification program you needed to pass in order to use
Firefox OS brand with your device - and guess what? Closed crap like ZTE Open
was passing the certifications. Mozilla was basically endorsing devices you
had to break into in order to be free to use them as you wish. How is that
different from Android?

I had high hopes, but Firefox OS disappointed me.

------
Neener54
I managed to get a developer phone with Firefox OS at a dev conference. I can
say that hands down it's the worst phone I've ever tried using. I used it as
my primary phone for a week and the operating system made me avoid doing
anything. Making a phone call was the most pleasant, but if I had to send a
text or try and use one of the apps I just found myself locking the phone. The
webapp as a phone app idea was just really unpleasant especially if you had
limited connectivity.

I admire Mozilla for trying, but that OS would have taken a miracle to get it
working in a good fashion.

~~~
hotcool
I seriously considered buying a ZTE - until I checked out user reviews online.
The os is universally hated.

------
smegel
> „Tier 3“

What's the down-up bunny ears? Does this mean anything or just a typo?

~~~
metasean
Quotation marks are done differently in different languages [1]. The author of
the article is André Fiedler [2], and he's from Saxony/Germany, where they
apparently use, what you called down-up bunny ears [3].

[1]
[https://en.wikipedia.org/wiki/Quotation_mark#Summary_table_f...](https://en.wikipedia.org/wiki/Quotation_mark#Summary_table_for_all_languages)

[2] [https://github.com/SunboX](https://github.com/SunboX)

[3]
[https://en.wikipedia.org/wiki/Quotation_mark#German_.28Germa...](https://en.wikipedia.org/wiki/Quotation_mark#German_.28Germany_and_Austria.29)

------
ksec
The bigger question is What will happen to those who has Firefox OS shipped
like Panasonic TV. ( Actually that is likely to be the only popular Devices
using it )

At first they say Firefox OS isn't going away and it will support IoT, so
development will continue. Panasonic even made a PR just so people don't freak
out and stop buying their TV set.

Now it is moved to Tier 3 support...

I really don't know whether i should blame Mozilla or Panasonic on this one.

------
simula67
> Let's say Android does not implement the new cool feature

If there is enough demand for it, someone can do a Kickstarter, raise enough
money, build it and push it into Android. Or some other company can fork
Android, add the cool new feature and steal Android's market share.

