> Presto wouldn't be so memory efficient on today's web;

I disagree. (I continued to use the last version of Opera Presto for a few year even after it was abandoned, and it continued to outperform other browsers on both platforms - Windows and macOS, though the macOS version was a bit more buggy).

Let's not forget that Presto already supported a lot of HTML5 features(1) before it was abandoned. (Even today, it works surprisingly well on most websites, though it does show its age a bit). And while the last few versions did seem to be a bit more resource heavy, I attribute that to development suffering because of the upheaval in the company - morale was low as many developers were laid-off while the management was also negotiating a sell out with investors. This naturally stunted the development of the core browsers parts in the end.

(Also, it was a suite and had an integrated email client, IRC, Torrent download manager, RSS reader, apart from the browser, all of which was packaged in a smaller size than Firefox or any other browser of its time!)

> when the majority of your revenue comes from companies who care about running on limited devices, of _course_ the company invested more in running well on them.

True. But let's not forget that Opera browser earned its reputation for being blazing fast, its tiny size and its low memory consumption on the desktop platforms long before it became a popular browser on the mobile platform. If I remember right, the first few versions of the Opera browser (then a non-free product) was less than 3-4 MB(2)!

> And I wouldn't hold up Presto as a great example of modularity or the ability to embed the rendering engine in other projects.

I can't comment much about this - The source code of Opera Presto is out there on the net, and it is definitely much easier to understand than the Firefox codebase. I also remember that the popular Macromedia (now Adobe) Dreamweaver used the presto engine at one point.

It says a lot about Mozilla that despite being older than both Chromium / Blink and Webkit, the latter are more popular in many open source and commercial applications because of the ease of use in coding and integrating it in their applications. A good example of this is QT5 which offers the QTWebView and QtWebEngine module (3) that allows you to embed webkit or chromium in your application, out of the box. Whereas qtmozembed is a barely maintained unpopular option for this same use (probably only surviving because Jolla develops their mobile browser for Sailfish OS using it).

(And I suspect this was a deliberate decision made by Mozilla after Gecko / Firefox became a cash cow for them - they just didn't want the code to be modular and easy to understand as it would hinder the creation of competing browsers, which would otherwise potentially cannibalise their own product. Ofcourse, with GeckoView this slowly seems to be changing perhaps on the Android platform, but I cynically suspect this has more to do with the fact that Firefox Mobile is not very popular on the mobile platform, and Mozilla now is looking to encourage developers to create even alternate browsers using their technology hoping it'll provide a filip for their own Firefox Mobile browser. That's certainly going to be interesting to see ... Another intresting tidbit I recall reading somewhere is that Mozilla also makes some developers sign non-disclosure agreements (4) which seems very odd and out of place to me, for an open source project.)

(1): https://en.wikipedia.org/wiki/Presto_(browser_engine)

(2): https://filehippo.com/download_opera/8.02/

(3): https://stackoverflow.com/questions/29055475/qwebview-or-qwe...

(4): https://medium.com/@smsnobin77/firefox-build-macos-f1f53d643...