Engineering code quality in Firefox
hacks.mozilla.org
hacks.mozilla.org
Trying to compile Firefox was already a challenge. That, and each compile took an hour. IIRC, Firefox is built on some esoteric architecture / design pattern that's definitely beyond the scope of design patterns undergraduate students are familiar with.
By the end of the term, no one discovered a 0-day, unsurprising considering half the class didn't even try. There were 90 students in the class, and I ended up being the only person to produce a JS payload that would crash Firefox in one of the newer HTML5 libraries. It's neither a zero-day or exciting or profitable vulnerability though.
Realizing everyone in the class would fail, the professor changed the grade of this project to only account for 30% of the grade. I spent most of my time on this project while disregarding the rest of the busy work for the class. In the end, I got a C grade while my peers who didn't even attempt to tackle this project received higher grades.
> ... I ended up ... neither a zero-day ...
> Realizing everyone in the class would fail, the professor changed the grade of this project to only account for 30% of the grade.
> I ... disregarding the rest of the busy work for the class.
It sounds like OP could not find a zero day (old_grade=0) and did not do any other homework (new_grade=0), therefore should have received max(0, 0), but received a C.
Things are much better these days, but there is still much inherent complexity in a project like Firefox.
At first glance, this sounds terrible. But when compared to software projects of comparable size, Firefox is hardly unique. Compare to compiling Chromium for example, or even the Linux kernel.
At one of the FAANG I previously worked at, it took an hour to compile JavaScript.
[1]: https://techgage.com/wp-content/uploads/2019/11/Compile-Perf...
Linux is almost trivially easy, only slightly harder than the usual configure && make and has very few dependencies.
Firefox is pretty painful but it's doable with a decent amount of care and bandwidth.
Chromium is a fairly typical google project where the recommended first step to building it is to become a google employee but some alternative workarounds are also available if that's not practical.
https://chromium.googlesource.com/chromium/src/+/master/docs...
At some point I started wondering if indeed I'd get the fix in faster by starting to practice whiteboard interviews.
For what it's worth, this is how it work's if you're a Google employee too.
That's very unfair imo. The majority of people I know in academia don't fit this profile at all. There is obviously disappointing stuff happening, but people generally still are working/teaching in good faith.
That's a general truth. You make it sound like people choose academia to somehow cheat the system and profit from free student's work or whatever. Make a real case for you thesis then.
Being suspicious of those who voluntarily become academics is odd.
Your work stands on the work of countless academic researchers and you run around "What did academia EVER do for us?" - the Monty Python sketch about Romans comes to mind.
If any of IT projects came from academia to the market, it's only because certain people were picked up by businesses that were onto something already.
It depends on university. On mine, most professors just see it as a job, something that one must endure until it's over. And when you bring to attention that what they're lecturing is incorrect or not proven they don't really care, again not all, but most, at least on my university. Just today I reminded the professor that there is a difference between a theory and hypothesis, their response was that they don't know if the theories they're teaching were tested or proven, but they are teaching this because that's what's written in the book...
That made me really sad, it's already hard to stay motivated to not leave the university because you need a certificate of a higher education to be taken seriously, but such behaviour from professors makes it even harder.
I've already expressed my worries to those in control of courses and they say that they understand but can't do much to change things because the curriculum that we have was accepted by the government.
Here in Slovenia people that work in the universities are paid by the government regardless of how happy or unhappy the students are, which is probably the reason for the situation in which we are...
How our universities work is that as a researcher a part of your duty to the university is teaching students. Unfortunately, fields of research and study subjects in most cases aren't aligned. Nobody will be researching basic subjects that must be taught to the students, and on the other hand a very specialized field of research might not be taught to anything but a small post-graduate course. This means that often professors will end up teaching an undergraduate course that has next to nothing to do with their field of study. In the end, someone must be teaching those introductory courses and for some subjects being taught the university might not have any professional researchers at all.
Professors are researchers first and teachers second. This is most likely the reason why it appears that teaching is "something that one must endure until it's over". Your professor might be a brilliant world-class researcher in their field and they pursue it with passion, but they might be teaching e.g. linear algebra to undergraduates twice a week based on "what's written in the book" to keep their job. As it turns out, teaching and research are quite different skills and they often don't coincide. When they do, you get some really amazing professors and I'm sure you have some on your course as well.
It's not a perfect system, but I've spent enough time in foreign universities where research staff was on-the-hook all the time and liable to get fired if students weren't happy with them. It's such a constantly stressful environment that I was amazed that people managed to do any kind of research at all. In the end, it's a trade-off. You can't have a university without either top-end research or teaching and we might have chosen a slightly different trade-off between these two than the countries you seem to look up to.
Anyway, I hope I've given you a new way to look at things and I hope you will stay at your university for more than just to get the "take me seriously" papers.
You don't know him at all, apart from a short anecdotal incident, where even OP does not portray him in a bad light.
Them are their users most likely are the #1 source of build documentation, bug reports and fixes in OSS
And remember: Chrome is the new IE.
(Since a number of people have misunderstood this quote in the past I'll explain it up front: 1. IE was in some ways technically superior to competition until they became dominant. 2. At the same time devs stopped caring about other browsers, and then 3. Microsoft lost interest in it. We are repeating this it seems, currently at step 2 for a few years already, waiting for Chrome to completely outcompete other browsers and for Google to abondon it like so many other of their projects :-)
Edit: I took the time to write down a slightly expanded version of the explanation above: https://erik.itland.no/chrome-is-the-new-internet-explorer-4...
Chrome is good enough. The interface is still streamlined. Microsoft didn't just lose interest in IE, but it became bloated with the toolbar. The UI wasn't well proportioned in general.
Web development wise, it was a struggle to be compatible with IE. Chrome may be setting the web standard for better or worst, but atleast developers are more comfortable developing and testing Chrome. The sentiment is that writing code to work I.E. would be exceptional, whereas now writing code for non-Chrome browsers would be the exceptional case. In fact, developers sometimes only test Chrome. Some popular E2E JavaScript testing frameworks only work with Chrome.
Also, I don’t know if there are examples of Chrome implementing non-standard behavior that rivals IE having an event bubbling system that was inverted from every other browser.
As a developer you get a lot for free by developing in Firefox, most importantly if it works in Firefox the it will likely work in all other browsers as well. This is, in my experience as developer and code reviewer not the case for code written and tested exclusively on Chrome.
This was once the case with IE, as well. Testing code in non-IE browsers used to be the exceptional case, and a lot of developers only ever tested in IE. There are countless enterprise applications that only work in IE even now, which is most likely the main reason that Microsoft is still keeping IE alive.
I'm using Firefox privately at home but for work, including work@home, I'm using almost exclusively Chrome. Chrome is just so much faster and the developer tools so much more polished than Firefox. DataView is 40 times slower in Firefox, and I'm using it quite extensively to read binary files. There is a Uint8Array hack/workaround that lets you write your own DataView that is 4 times faster in Firefox, but 10x slower in Chrome, so it's not an alternative I'm going to use.
Chrome has improved DataView 2 years ago: https://v8.dev/blog/dataview
A rather basic jsperf is here: https://jsperf.com/dataview-float-int The results are that the u8 hack is equally slow in firefox and chrome (~90ops/sec), the DataView version is 10x faster in chrome(945ops/sec) but almost 4x slower in firefox(25ops/sec).
There must be something fundamentally wrong if apps can't stfu and be at 0% while in background with simplest use case. I am going back to close app's when I am done using it.
I would not be surprised if someone tells me that parts of Safari hook into private APIs in the kernel, the graphics driver and the other parts of the graphic and input stack to achieve the (measurable!) performance advantage over other browsers. For me personally, this is uncompetitive behavior that should be punished, but oh well, anti-trust legislation isn't exactly something that got much use over the last decades :(
Setting aside private APIs as I have no idea what Safari does or doesn't use (although vast portions of it are open source, enough that you can compile modern versions of WebKit and "upgrade" the ancient WebKit on PowerPC Macs), another browser could be just as closely integrated as Safari. Obviously, the cost/benefit ratio is awful for Mozilla and Google, so they won't, but why should Apple cripple their own software? Safari's development costs, as part of MacOS, are funded by profits from Mac sales. Safari is deeply integrated with MacOS which is in turn deeply integrated with the Mac.
In my opinion the whole point of the Mac is this vertical integration, and the main value-add of Apple's sphere. If you don't value that, there are cheaper options where cheaper and more flexible software is available.
To me, an anti-trust suit would make sense for Safari on iOS, where Apple has locked all competitors out (in practice). Saying Apple should be fined for Safari because it's more integrated and efficient and that's not fair to Chrome and Firefox seems a bit silly, especially given (desktop) Safari's relatively small usage numbers. All IMO of course.
No, only for not giving everyone a fair and equal level of access. I'm not against Apple deeply integrating Safari into the OS, but they should allow competition to enjoy the same level of performance that their own stuff does.
In the absence of any evidence of this — have you looked at the open source releases? — why is that more plausible than a team employed by a hardware vendor which cares deeply about user experience and battery life prioritizing use of the platform features and talking with other teams at the same company? Part of what makes things like Firefox' compositor work hard is that they support multiple other platforms so the Safari team can easily be ahead without anything underhanded simply by virtue of not needing to support 4 major platforms.
It would be interesting to compare the safari budget/manpower. Even given that, I would imagine safari only has to support one-ish OS, and probably has help from the OS group.
That said, it's worthwhile remembering that WebKit does very much maintain all the abstractions to be cross-platform (and Apple do still maintain a Windows port), even if it does try and leverage plenty of OS libraries in a way neither Firefox nor Chrome do.
Certainly Apple's WebKit port uses Core Animation heavily, which is definitely heavily tied to the compositor in the window server.
At some point Google search results page also would spinn up one core on my machine one or twice a minute if left unattended but last I saw that was years ago. (FWIW I don't use Google search much these days, so it might slip by without me noticing.)
IMO background activity should need an extra permission similar to notifications and geolocation.
But we need to sort out UX (and start punishing the companies that "misunderstand" GDPR to mean they just need to add another popup) as it is starting to get bad now.
BTW, this needs to be fixed across a number of situations. There's no reason why I would want to allow a build tool to access all my projects just because I want to allow it to access one project. (Github and Azure Devops, I'm looking at you)
Things (on the same constrained resources VDI) get even worse with actual "complicated" content: viewing the same page which contains an animated GIF, Firefox seems to prioritise playing back the content, even at the expense of noticing/obeying user-interface interaction like closing tabs and opening menus: i.e. gifs will keep playing (very slowly), but it won't notice UI clicks on its interface for many seconds seconds.
In the same scenario, Chrome responds to UI events much more quickly (very nearly instantly).
It's possible this is due to hardware acceleration or something, but as both are running in the same VDI that barely seems to have OpenGL 2.0 support (I can't run modern OpenGL apps), that seems unlikely to me...
I wish IT auditors understood this concept better.
Sorry for the following rant, but I really don't think of Firefox browser when I think of code quality. (Still don't even though it has improved a lot in some areas).
When it comes to browsers, I still feel the old Opera browser (presto), that had more features, was blazing fast and small in size (in memory) is a very good example of a finely engineered software. In the early versions they really cared about optimizing for performance, using less memory and less power (on mobile devices) - I am amazed that years after, modern browsers are bloatier now than ever and just don't seem to care as much about these aspect as much as Opera did.
Questions like how modular is Firefox, how easy is it to customize Firefox (add or remove feature from the code), how easy is it for someone to use the Gecko rendering engine in their own project etc. all kind of indicate the bloatier, messier nature of the code within Firefox (in my opinion).
It's like browser developers now a days only care about adding more features (read bloat) without considering any constraints ...
But ultimately a lot of this comes down to different considerations: 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. 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 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...
I don't suppose it's been open-sourced, has it? It would be great to have an alternative browser engine out there, instead of just three (or two and a half, depending on how you count Blink and Webkit).
No, it was leaked illegally. Opera filed a lot of DMCA complaints with many online Git repository services to get the code removed from them. But you can still find it if you Google hard. I also recall reading that some Russian developers were working on the leaked code and had also released a "newer" version with some patches (Opera presto was really popular in Russia) but I couldn't find it.
There is another little known open source browser project independent of Gecko, webkit and Blink currently being developed but I just can't remember its name, even though I tried compiling it on my system ... damn ... I'll post an update when its name comes to mind.
Just about all of the major browsers earned their reputation for being blazing fast, tiny, and using little memory. And those attributes are well-deserved at their launches. Then real-world pressures kick in -- it turns out that although people love small and fast, that doesn't do them much good without support for X (or being able to handle condition Y), and there are many, many values of X (and Y). Small and fast plus X would still be nearly as small and fast, but small and fast plus all X is decidedly not. Meanwhile, the other engines are evolving too, and everyone more or less converges on roughly the same performance characteristics. We [I work for Mozilla] end up mainly competing on different metrics, assuming we all keep up with "good enough" speed and size.
> It says a lot about Firefox 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.
Indeed it does. Firefox abandoned embeddability long ago, and only recently decided to try again with GeckoView. And yes, it was a deliberate decision, but not for the profit motivations you're suggesting. It was based on maintainability and developer velocity, when we realized we were not going to out-compete Google with engineer headcount. We had to simplify and reduce our nonessential complexity overhead.
> Mozilla also made some developers sign non-disclosure agreements
Why throw so much shade? I'm not sure exactly what you're referring to, but Mozilla does indeed sign NDAs for stuff that people will only make available under NDA, and there is some insider knowledge that can only be released under NDA or not at all. That was far more common with FirefoxOS, because let's just say that the mobile industry isn't quite as open as desktop. (Massive understatement!) But generally speaking, we have very little to gain from keeping any technical or architectural stuff private, and quite a bit to lose. We're still a community-based project, and get very substantial contributions from non-employees, admittedly much less than in that past as a percentage (for a long time, we hired up many of the better contributors, which cut both ways.) The vast majority of our discussions happen in open forums (Matrix instead of IRC now, but still mailing lists + newsgroups + various other things). The only private technical stuff I ever deal with is security-related, and even there we're very good about opening up bugs after they've shipped.
Not like Opera though who made performance and small size (and power optimizations) as their core philosophy.
(This was the browser whose popularity even frightened Microsoft, whose infamous Internet Explorer had I think nearly 80% market share at the time. So much that they deliberately ensured that their website broke on Opera. And it forced them to reluctantly focus on the Trident engine that powered IE again - till then, they had been ignoring IE because Microsoft was rightly genuinely frightened of competing on and with the web).
Starting with the mindset of making a fast, small and efficient engine that could run on constrained systems was the reason Presto outshined other engines. Later this extended to optimising their code for lower power consumption too.
That's the main difference with Gecko, Chromium / Blink and Webkit (to a lesser extent) who did focus on optimising for speed but were a bit more lax on the memory and power aspect and only started addressing it after users started complaining (and ofcourse, only after they made mobile platform a priority). I still remember how we users grumbled when Opera installers crossed the 10 MB size :) ... but Opera still managed to keep us hooked by introducing a plethora of features while still trying their best to maintain an efficient code base and deliver it in a smaller package. Compared to it, equivalent versions of Firefox and other browsers at that time (and even today) seem very bloated in comparison because it's not a priority to them.
> Then real-world pressures kick in -- it turns out that although people love small and fast, that doesn't do them much good without support for X (or being able to handle condition Y), and there are many, many values of X (and Y).
Sure, but this doesn't apply to Opera. Opera kept their high standard and core philosophy intact till the last version before management failed them. It maintained feature parity with competing browsers till the end, before it was sold off and dumped for Blink to cut costs.
Opera didn't fail because it couldn't keep up with web standards or in introducing new features, but because of poor business management.
If Opera's founder is to be believed, they just couldn't allocate enough resources for keeping track of, and patching broken popular sites that don't follow web standards. (This is the reason he gave for abandoning Presto, and selling his company, and then choosing Blink for his new Vivaldi browser).
Opera the business failed, but their product was top notch and better than their competitors till the end. If I remember right, I stuck with it till 2017-18 before I moved on to Firefox and later to Ice Cat, Pale Moon and Safari.
> We [I work for Mozilla] end up mainly competing on different metrics, assuming we all keep up with "good enough" speed and size.
Yeah, that's spot on - that's what I've always felt about Firefox, that Mozilla's philosophy is to be "good enough", and that's why to us consumers the product (Firefox) feels "average". There is nothing much to feel excited about in terms of performance or features. That's the area (performance and features) that Opera excelled in.
> And yes, it was a deliberate decision, but not for the profit motivations you're suggesting.
I am sorry but I don't believe this - it was very much for profit too. I do believe it was to ensure the project isn't forked easily to build a competing product. Just look at Goanna / Pale Moon struggling to maintain quality and feature parity now. (Ofcourse they are also struggling because of the design decisions they made).
Chromeless Firefox was a very interesting project. Killed before it could become popular. Vivaldi browser is based on a similar idea and its enjoying some success.
My point is that it is a smart decision from a purely business perspective - look at all the relatively successful fork of the Chromium browser. And browsers based on webkit. There are many people who don't like the current direction of Mozilla and / or Firefox and they would gladly jump on to decent a fork if it were easy to do so.
> It was based on maintainability and developer velocity, when we realized we were not going to out-compete Google with engineer headcount. We had to simplify and reduce our nonessential complexity overhead.
That's MBA manager speak - lots of buzzwords that don't really convey anything meaningful. ;)
My perspective is that as an open source project, Mozilla shouldn't sacrifice product quality for short-term gains. They should fix bugs rather than focusing on new features or products even if they lose ground to other browsers. Their focus should be on quality rather than trying to compete with a corporate product and keep pushing release after release just for the sake of competing and "staying relevant".
> Why throw so much shade? ... we have very little to gain from keeping any technical or architectural stuff private, and quite a bit to lose.
That is exactly why I found it interesting that an open source project was asking volunteers to sign NDAs! (https://medium.com/@smsnobin77/firefox-build-macos-f1f53d643...)
As for the snark against Mozilla - your perception is right. I do have a certain level of antagonism against the foundation. It stems from the following reasons:
(1) They are a million+ dollar foundation and still produce an "average" product. Comparing them to other open source projects with much, much smaller budgets that produce high quality softwares really irks me.
(2) Some of their recent management decision range between foolish to greedy. E.g. Forcing Pocket on unsuspecting users (I strongly suspect some members where bribed to push this integration). E.g. Including closed source DRM in the browser (if users want to download a plug-in to watch DRM protected media, then they should have a choice to do so. Google and Cisco, if I remember right, now have a monopoly on this because of Mozilla).
About DRM: Mozilla fought against it, and caved when it became clear they could not win. But Firefox users still have to opt-in to install the binary blob (eg. Widewine), it's not bundled in the browser.
While I do believe there was genuine opposition to this move within the community, I think the real decision makers had already made up their minds and just made a show of "discussing" it. I feel they did it under pressure, and perhaps were even induced with promises of more revenue, from Google.
And where was the question of really caving? All they had to do was ask Google (or any other company) to develop a browser plugin for Firefox and let the user decide if they wanted it (when a user encountered it on a site, produce a pop-up alerting the user to the plug-in required). And maybe then we would have some real competition in this space too as a new plug-in war would have developed ...
> But Firefox users still have to opt-in to install the binary blob (eg. Widewine), it's not bundled in the browser.
That's not true - it's been opt-in by default for a long time. See here - https://imgur.com/a/iCTmnzN ...
I think since EME free versions were released, at some point a policy decision was taken to make it "opt out" in the usual general releases, as a technical person would rather opt for the EME Free version or go through the options and disable it if they so desired, where as a non-technical user might get confused about EME or DRM or plug-ins ...
I fear that the Google DRM binary blob has actually made it much easier for them to uniquely fingerprint every Firefox user with EME / Widevine despite all the ad-blockers and anti-fingerprint extensions or techniques being used. In other words, I fear that Firefox (knowingly or unwittingly) has aided Google in killing privacy on the web.
The problem with beliefs is that there is no option to disprove them. Mozilla said they fought against it, the people who were there say they did fight against it, you don't believe it and think it's some kind of "show" put up.
> All they had to do was ask Google (or any other company) to develop a browser plugin for Firefox and let the user decide if they wanted it (when a user encountered it on a site, produce a pop-up alerting the user to the plug-in required).
And what incentive would companies have had to do that? Firefox simply doesn't have the market share to force anyone to develop for them. Even worse, Google has every incentive to not do it and instead pop up a banner "hey, looks like your browser doesn't support YT, use Chrome". People who argue that Mozilla was wrong to accept the DRM blob never have a good answer for this and usually then end in "people would have seen that Mozilla is right and boycotted YT" or "who cares if Mozilla has only 1% market share, it's far more important to never make any compromise".
It wasn’t just Google: Microsoft and Apple also sold both DRM systems and content, and all three loved the idea of getting rid of Adobe. I never could get anyone to offer a credible theory for how Mozilla could fight those odds.
- Firefox has enough of a marketshare that nobody ignores them. - If Google wouldn't, someone else would have. - The content providers (Netflix, Prime, Hulu etc.) would have forced them to do so.
I don't buy these arguments. And the fact that Mozilla makes it opt-in by default shows that the Mozilla board is now more concerned about revenue from Google and squeezing it as much money from their product than actually improving it. I wish the Firefox developers had more voice.
What design choices? If they would ride on Firefox release cycle, Pale Moon would lose its advantages.
How naive to think that copying your competitor makes you gain many users!
Edit (references):
1. https://www.dedoimedo.com/computers/firefox-addons-future.ht...
2. https://www.dedoimedo.com/computers/firefox-29-sucks.html
3. https://www.dedoimedo.com/computers/firefox-suckfest.html
4. https://www.dedoimedo.com/computers/firefox-disable-australi...
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.
That's not surprising as current Firefox has indeed made improvements. Your argument is disingenuous if you aren't comparing Opera presto with the equivalent version of Firefox of the same period. Firefox than couldn't even manage 10-20 tabs, without high RAM consumption, whereas Opera Presto could easily handle around 100+.
> Morale only really collapsed after the move to WebKit, nor had there been lay offs for several years prior.
I didn't claim the layoffs started years before they were sold. Opera was a solid company for some time. But many employees were laid off prior to Opera being sold to their current owners, mostly the marketing and support staffs and some developers. Morale was indeed low in the company. And rumours were already swirling around in Opera forums and popular Opera fan blogs that Presto would be dumped. (And it was dumped ultimately for Blink, a fork of webkit, created in partnership with Google).
Your point about some memory issues with engines, compared to the previous versions, are correct. Despite those issues, Opera Presto was still better than Gecko during the same period.
My point is to compare Apple to Apple - highlighting the weak point of a browser engine, whose development has since been abandoned, by comparing it to Gecko's current modern avatar doesn't make sense, when my argument is that Presto was a better engineered product than other browser engines of its times. Ofcourse I agree that Firefox has come a long way and is far better now. (That's why I shifted to it after Opera died).
> The graph of module dependencies was ... so in many ways it really wasn't modular.
Perhaps so. It is still easier to understand than Firefox's mish-mash of a codebase, because it is smaller and better coded.
Let us assume that is true (even though it isn't) - what's Firefox and other browsers excuse for running slower than Opera on these same sites, during the same period?
Opera presto supported a lot of the features of HTML5(1). So it didn't necessarily "do less" than the others.
And second, if you really want to compare Opera presto with other browsers, you should do it with the versions of the competing browsers that were available then. (I still remember how people complained about Firefox consuming a a lot of RAM when you opened more than 10 tabs, where as Opera could easily handle 100+ tabs(2) without any complaints.)
Even otherwise, if you test it out yourself today by downloading an Opera presto version (version 12.15 / 12.16) you will find how usable it still is on 70-80% of the websites today, even after not being developed for years now).
(1) https://en.wikipedia.org/wiki/Presto_(browser_engine)
(2) https://forums.opera.com/topic/19313/how-to-retrieve-acciden... ... and ... https://portableapps.com/node/59581
Oh ok. I see the confusion - I was speaking specifically about Opera (Presto engine) versions. Not the current Opera Chromium clone. And the point I was trying to make is that it was a much, much better product than its competitors. And if it had survived, with the original team still working on it, it still would be better than Firefox / Gecko and Chrome / Blink of today.
People switched because Presto wasn’t perfect (I had plenty of big reports) and it was falling behind with each release as Mozilla and Google really hit their strides.
I was talking about Presto in comparison with browser engines of its period. As for people switching to others because "Presto wasn't perfect" - obviously, even an Opera fan like me did too, because the project was abandoned and started showing its age! My point was that it was a much better engineered project than its competitor of the same period and if its development had continued with the same philosophy, it would still be one.
When I say Opera Presto was better, I do mean better than Gecko, Trident, Webkit of that period, not better than the current modern versions of these browser engine.
Back then, good scrolling performance meant moving one page of thumbnails at a time, not continuously scrolling many times more thumbnails of significantly greater resolution.
The better lesson I’d draw from this is that it’s healthy to be skeptical when people say we “need” a huge pile of JavaScript for everything. If you let a modern browser run without layers of heavy code it’s usually easy to get the response times faster than the thresholds where users perceive it as instantaneous.
I think I just fail to understand the true complexity of a browser, but how is Firefox 21 million lines of code? How can a browser be 21 million lines of code? That just seems so large for what a browser does.
You mean Emacs? All it needs is a good editor :)
What tangible advantage would this have? Having competing browsers seems possible, but since end-users wouldn't be choosing individual browser components anyway, it wouldn't actually improve anything.
Choice matters. Sometimes you have to make a choice on behalf of your users. I think that’s what the industry as a whole has done here. Nothing is preventing people from rolling their own modular web browser. Maybe things like Beaker Browser and TOR Browser are versions of that same idea but approached from a specific use case.
Thanks for this comment. I think your idea is good but not for the same reasons that a web browser suite is a good idea for most non-technical users.
Every time I see someone working on a FF bug I’m cc’d on, I marvel at how many files they have to touch to get anything done. One key binding missing, because they’re not using the system text field? Hundreds of lines of diffs, spread across a dozen source files.
That is what html+js is. Why do you presume a different standard would be more efficient in the end?
The web is good enough for pure content delivery, but for more advanced interactive applications, the limitations are a huge waste. For instance, I have a computer at home with a 12-core, 24-thread processor, but web applications are basically single-threaded with some very limited support for web workers. I'm also limited to basically one language, which is garbage collected, so performance and memory usage are significantly worse than they could be. And as far as graphics, you're limited to WebGL which is ages behind the state of the art in terms of graphics APIs.
Basically there is a whole universe of tools out there for software development, but if you want to target web you're limited to a handful of poorly performing, hacky options.
For my work, we use several web applications to collaborate. As someone who works on highly optimized user-facing software, it's frustrating to understand how poor these web applications perform given the potential of modern hardware.
The reason we use them is because you can send anyone a link, and they're into the software in one click. There's no reason we couldn't have the same experience for native software, where when you click the link your computer downloads a native binary and runs it in a sandboxed environment against a standardized system API. It would take a lot of careful work and planning, but there's no technical reason it couldn't exist, and it would be so much better for developers and users.
Also, there would have to be some GUI framework that works well across all devices, phone to desktop. That alone would be massive undertaking.
I agree there is no technical reason, but once you consider all limitations and let some time pass in the end you might up with something similar to what we have now. For example you might standardize on a current graphics API, but in a few years: guess what, you have an outdated API like webGL now.
Not necessarily. You could have different binaries for different architectures. All you need is a consistent system interface with a well-specified ABI, and the client would just have to request the binary for their architecture.
> That’s webassembly, which is coming up.
Web assembly still has the limitations of running inside the browser. It's still single-threaded, and also the file size is pretty large compared to a binary.
> Also, there would have to be some GUI framework that works well across all devices, phone to desktop.
If you had a consistent system interface, you'd only have to do it once.
> For example you might standardize on a current graphics API
I mean Vulkan is basically this. And graphics API's are converging not diverging: modern graphics API's are all structured in a very similar way, since they're all just wrappers around the low level functionality of the GPU at this point.
I'm not saying it would be easy, but the reasons we don't have it have more to do with the fact that it would be difficult to get buy-in from OS vendors than it has to do with the technical problems involved. From a technical perspective, we could easily do way better than modern web.
Also web is basically a single-threaded runtime environment. For the foreseeable future, increased parallelism is the main way we can expect to get increased computing performance, and it's basically not available on the web.