> 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).
Loading my profile on Twitter leads Presto to use more memory than Firefox. (Though really that's a terrible benchmark, probably want to disable in-memory caching.)
> 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.
In all due respect, you sound like you have no idea what you're talking about, neither with when there were lay-offs or with how morale was internally. Morale only really collapsed after the move to WebKit, nor had there been lay offs for several years prior.
The increases in memory consumption were primarily down to changing trade-offs with performance v. memory consumption, and certainly a fair number of these were configurable at compile-time (heck, Futhark stayed around for a while after Carakan was shipping on desktop precisely because it's memory consumption was lower).
> 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.
The graph of module dependencies was… quite something. There was a _lot_ of mutual dependencies between modules, so in many ways it really wasn't modular.
As for embeddability, I'll point out that typically there were multiple implementations of platform layer stuff across the company (heck, Core maintained an almost entirely separate implementation to Desktop for all the platform layer stuff, despite the test browser running _on the same platforms as Desktop_). You had to write a lot of code to get the browser running on a new platform.
As for all your comments about Gecko's embeddability, I'm not even going to give them a response; they've largely been covered already.