> And on top of this, Mozilla decided to shoot for (super) low-end devices as their main target - presumably because their bizdev people had spotted a theoretical opportunity, but failed to connect with engineering, or vice-versa.

Having been there (ex mozillian, lots of time spent on FFOS), I wouldn't characterize it like this. The leaders of the project were two engineers, not a pointy hair on their heads (at least at first).

There were certainly plenty of us who felt like trying to cram this much into a low-end device was insanity (when was the last time you saw any web browser use under 128mb of ram?), and we definitely raised this objection. I feel like the pathology I observed was more planning fallacy / overoptimism on the part of engineering leaders than anything else (I'd certainly be the last to claim that I've never been guilty of that).

There's also another fallacy that I don't have a name for, which is basically "this is the only (way we see how) to do it, so we're going to make it work." That is, it was hard to imagine a FFOS device competing with a high-end device, so they decided to focus on the low end. That's the only way we can do it, so we'll make it work. But that causes you to perhaps lose sight of the real question: "can we make it work?"

It's not clear to me whether FFOS would have had a shot if not for the focus on low-end hardware. Having been there, I feel like the architecture itself was really hard to program against. Bugs that should have been easy -- "make sure the alarm clock actually goes off", "don't leak apps" -- required lots of specialized knowledge and time to fix. But certainly a lot of time was also spent on performance/memory optimization.

Just my two cents. A lot of smart people worked hard on this project for many years, and there were many impressive technical accomplishments along the way. Look up Nuwa if you're interested; that shit is nuts.

> They actually have a time-honored tradition of following in the footsteps of Opera when it comes to ways of making money.

"Opera had it first" indeed. :)

Well at least it is refreshing to learn there are Moz, or ex Moz who think better. I think the conclusion is simply,

planning fallacy / overoptimism on the part of engineering leaders than anything else

So yes, Mozilla is simply a poorly ran organization.

To be fair, the "low-end" devices Firefox OS were targeting were miles more powerful than what Opera Platform targeted a decade prior, and JS VMs are far quicker than they were a decade prior… I'm not sure it's so obvious that low-end devices doomed it to failure (of course, you actually worked on this stuff unlike me!).

I think it's worthwhile to remember at the time Firefox OS launched much of Android ran on the Dalvik VM, so it wasn't so clear cut that the approach was so doomed to fail.

(Hi Geoffrey, ltns! :) )

The execution of the code, be it javascript on some modern engine or Java/Dalvik bytecode - that isn't typically the performance bottleneck. It is fast enough now.

I'm not an expert on this (this is where I thread on thin ice), but my understanding is that the HTML/CSS logdoc/layout tree model is inherently non-performant compared to a more traditional hierarchical windowed object oriented model. It is too easy to write HTML/CSS that is not performant (it's way too easy to accidentally cause performance issues), while it is a lot more natural to write performant windowing/OO code. And inversely, harder to write code that is not performant.

(Hi. :))

It depends a lot on what you're doing, and how much data you're processing. If we go by the premise that you're processing more data locally than you would in a web app (because you don't need to worry about the latency and you don't have a server to do the pre-processing and filtering of the data before it reaches the client), then actual VM performance is more significant. The last time I looked at any profiles of browsers on Gmail or FB, JIT'd code actually accounts for several of the most expensive functions (and you will notice if you disable the JIT). JS performance does matter—even if DOM performance dominates in the case of the common website (and note that Mozilla has actually been doing quite a lot of interesting work around teaching the JS VM more about the DOM, including rewriting parts in JS, which allows JIT optimisation to happen).

It's definitely true that it's easier to write non-performant code using HTML/CSS (and <canvas> and WebGL don't really help here—because it's hard to ensure data gets correctly passed to accessibility layers), but I think that the majority of mobile apps are simple enough for it to not be a concern.

I haven't done profiling of firefox os on a crappy device...

but my suspicion is that it really is as simple as: even really-well-optimized html/css/js that needs to go through a browser core will suffer performance-wise compared to something with 10-15 less layers of indirection. (Like a traditional windowing toolkit.)

The Android UI toolkit isn't exactly efficent (ha!), but still seems to beat Firefox OS on super-low-end hardware judging from the reviews I have seen.

The internal windowing toolkit and java-like mini language with a VM that we made for Opera Mini 5/Opera Mobile 10 with both J2ME and C VM implementations was like 3x faster than the Android UI toolkit with Dalvik for typical windowing tasks. Without any super-fancy optimizations...

As a practical matter, my experience of using FirefoxOS everyday is that performance is not the main issue. Of course it could undoubtedly be improved, but it's acceptable, particularly once you put it onto reasonable hardware (i.e. not the $40 phones).

Much more problematic is the lack of "premium content" i.e. services that — even if they are basically just webapps — don't work except on Android/iOS. This is a particularly vicious cycle; it's hard to convince anyone to put in the effort to support minority platforms, and it's hard to get users unless you support the same content as other platforms (see also: Windows Phone, which by all accounts is an excellent product that almost no one uses).

There's also the fact that FirefoxOS is some years behind the other platforms in terms of developers and the competition has ~infinite resources, which means that some parts are lagging behind feature wise.

Having said all of that, I don't think that Opera is a bad analog for the difficulties FirefoxOS faces, only it's not Opera Platform specifically but Presto in general. It had the same kind of issues with limited support from content creators and relatively available resources.

The indirection is a problem with existing browser implementations (and some spec issues, such as lack of Typed CSSOM, which is the current subject of work in the WGs). There is no fundamental reason that I can see as to why there needs to be a gap between the hardware and the graphics and layout of Web apps.

That sounds intriguing. But.. how?

Look at Servo and WebRender (disclaimer: I work on both), or just read "Fast and Parallel Webpage Layout", Meyerovich 2010 for much of it :)

CSS isn't less efficient than a traditional windowing model. In fact, its declarative nature is a big help when adopting legacy content to modern architectures. The "WM_PAINT/C++ code that calls GDI" model is not easy to adapt to multicore and GPUs.

This is not to say that the browsers of today are optimally architected, of course. (In fact, I think they're quite suboptimally architected for 2015 hardware. The "it's too easy to fall off the fast paths" problem of HTML/CSS is a symptom of legacy browser architecture, not a problem with the layout/styling model.)

Opera platform was not running modern mobile touchscreen apps a decade ago.

The problem is that the phones currently dominating the market in developed countries have native apps, with slick interfaces - enabled by mid to high end SoCs.

Trying to produce vaguely similar experiences with low-end SoCs is going to be very hard, even without the additional handicap of doing everything with web technologies.

If anything, the only way that could've worked in the current market is on ultra high-end phone hardware, and with a focus on privacy & security to attract the rich & technically savvy end of the market.

+1 interesting.

Started using Opera since ~2000 and really liked it. Really innovative (tabs, mouse gestures, download manager, ...) and fast! Even an email client was included :) !

But replaced it with Firefox by the time FF had tabs and was fast enough, due to 'trust/privacy' reasons. For the same reasons I do not use chrome.

And if FF keeps disappointing me and Opera gains trust I can imagine a switch :) (hmmh, but how if closed source?)

"We" (I have since left Opera Software) really screwed it up with the desktop browser around 2004. Management (i.e. the then-CEO Jon) was too worried about recurring revenue to pull that obnoxious ad banner in the free version until it was too late. At the time the desktop Opera had superior performance compared to Mozilla/Firefox.. but wasn't free/ad-less. It was really depressing to watch. (But at the same time, I didn't have to make payroll for 170 people each month, so who am I to judge those decisions without having detailed insights into the financials? I guess I am expressing my frustration of the lack of a silicon valley-style funding.)

To his credit, Jon a year later championed that Opera Mini needed to be free/without "in your face ads" in the critical first couple of years. This allowed it to reach 250+ million monthly actives (it still has that!). And we did came up with really lucrative monetization models later on that worked without sacrificing the user experience.

I'll argue there was a later screw-up on the desktop browser (and really mobile too): Unite sucked resources from much for a long while, failure to tackle some of the technical debt (things that manifested itself such as the integer maths used for percentage values in CSS, contrary to every other browser out there, and that went unchanged as layouts became increasingly complex and the web relied ever more heavily on CSS), and in later years general lack of investment (while Opera was posting record profits on a quarterly basis) in Presto leading it to fall further and further behind the competition causing ever worsening site-compatibility issues.

Well, yeah, there was a serious of screwups. :)

I don't buy the argument about a lack of investment in Presto. IIRC there were like 90 (most of them really good) people working on Presto at its peak. And we still couldn't keep up. (And most of those issues were about lacking desktop market share, which caused sites to de-prioritize Opera, anyway.)

From memory it was a touch more than 90—and while I never ceased to be amazed by what we achieved with the resources we had, everyone else was expanding while Opera didn't, despite clearly having the money to do so.

When it comes to lacking desktop market share, it's undeniable that has an effect on site compatibility—people kept on supporting IE6 till a few years ago, after all, despite all its flaws. If Opera had more marketshare, it could've afforded to not keep up (though then we'd have articles about how Opera is the new IE!). I think, however, site compatibility was less about marketshare in later years and more about ancient incompatibilities (percentages rounding down, keyboard events, range events, selection, document loading/unloading) that were increasingly important in an increasingly dynamic web. People were deliberately deciding not to support Opera at that point because it involved more than a trivial amount of work because of bugs like those and the lack of marketshare.

Do you mind sharing a few of those lucrative / non-annoying monetization models? I'm curious. And thanks for the insights into opera!

For desktop: Search engine affiliation deals became increasingly lucrative (partly dependent on the market), especially for the defaults (in both the search engine bar and the search box on the new tab page, which were sold separately). The other major source of income for desktop was the default Speed Dial settings.

There's a fair overview available in the quarterly reports.

I think that's still too recent, sorry. People might get upset. Ask me again in five years. :)

Apologies, I didn't mean to ask for anything proprietary; I should have made that clearer. Just what someone familiar with the product would know.

No worries.

Actually, when I checked just now I saw that I can share it since they actually have published a nice brochure about the scheme :).

http://www.operasoftware.com/content/download/5572/205427/ve...

Basically the scheme was: get lots and lots of users. Then go to each operator and say.. hey.. you know these users that you are having a really hard time to monetize because you don't have a direct in-app/phone channel to them? We have an app that (for example) 20 million of your customers use every month. Our offer to you is that for a cost for X USD/month/user we will expose your services in the default speed dial of this app that your customers love to use. This worked exceptionally well.

Opera was the only browser that would run acceptably on my even-then-way-old 16 MB-RAM machine back in 2000.

We could add Ubuntu to this list, unfortunately. As a side note, I bet cordova/phonegap and Ionic have had more apps built with the web platform on top of existing platforms than these devices have (probably by several orders of magnitude). I just feel like a new OS and device platform is the wrong way to achieve the goal of preserving the open web.

> The product name was "Opera Platform".

Thank you - I didn't know about this.