5 ms·

Most of you are probably not aware that Opera Software (where I spent a decade on Opera Mini/Mobile) went down the same rabbit hole around 2002-2006, spending m

• raphman_ 11y ago
  > The product name was "Opera Platform". Thank you - I didn't know about this.
• karussell 11y ago
  +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?)
  • johansch 11y ago
    "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.
    • StavrosK 11y ago
      Opera was the only browser that would run acceptably on my even-then-way-old 16 MB-RAM machine back in 2000.
    • gsnedders 11y ago
      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.
      • johansch 11y ago
        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.)
• gsnedders 11y ago
  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.
  • johansch 11y ago
    (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.
    • gsnedders 11y ago
      (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.
• yesimahuman 11y ago
  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.
• jlebar 11y ago
  > 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. :)
  • ksec 11y ago
    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.