7 ms·
The browser engine landscape presents an interesting paradox: we have an open specification, yet multiple implementations with their own quirks and incompatibil
by rrgok 2y ago
The browser engine landscape presents an interesting paradox: we have an open specification, yet multiple implementations with their own quirks and incompatibilities. This seems to undermine the very purpose of standardization.
Consider our current situation:
- The spec is largely influenced by the same big tech companies that develop the engines
- Major engines (Blink, WebKit, Gecko) are all open source
- Significant engineering resources are dedicated to maintaining compatibility
What's the actual benefit of this redundancy? In other domains, we often consolidate around reference implementations. While I understand the historical and theoretical arguments for implementation diversity (preventing monoculture, fostering innovation, avoiding vendor lock-in), I wonder if these benefits still outweigh the costs in 2025.
I'd be interested in hearing perspectives on whether maintaining multiple engines is still the optimal approach for the web ecosystem, or if we're just perpetuating technical debt from an earlier era.
- paulryanrogers 2y agoBecause reference implementations are often less efficient. If the standard exists as an abstract interface then future implementors can make different tradeoffs.
- deleted 2y ago[deleted]
- herrherrmann 2y agoIf there was a group/vendor you could trust to develop such a universal engine to rule them all, that could work out. But, alas, no big tech company could ever be trusted with such a task (they would try to push their agenda, e.g. by preventing ad blockers).
- rrgok 2y agoHow is that any different from now? Look what happened recently with Mozilla and Firefox...
- bad_user 2y agoI think that people should look at what happened recently and realize that absolute nothing noteworthy happened. And Firefox is still the only browser engine with support for uBlock Origin, on Android too.
- anonym29 2y agoWhoa, slow down there. You can't just go around asking people to read first-party sources and think critically on their own about an issue without getting their opinion from their feed or influencer of choice. That's an unreasonable and insane expectation! /s
- immibis 2y agoThe first-party source is Mozilla themselves skirting around saying, but very heavily implying they are now selling unspecified data about me to unspecified actors, in a legally binding way, then walking it back with a pinky promise that is not legally binding, so doesn't actually mean anything. Have you read the first-party sources?
- anonym29 2y agoThe narrative you gave above is by definition not a first party source. Here's a first party source explaining your misunderstanding of the situation: https://blog.mozilla.org/en/products/firefox/update-on-terms-of-use/ https://blog.mozilla.org/en/products/firefox/update-on-terms... And here's another credible source explaining Mozilla's mistake in making this decision based on language that was only present in a draft version of the CCPA, as opposed to the final version, but which also made it to Wikipedia: https://news.ycombinator.com/item?id=43276624 https://news.ycombinator.com/item?id=43276624 Most of the conversation on this topic never moved past the first misunderstanding, just a bunch of irrational kvetching at Mozilla by people who read an (incorrect) summary of the situation.
- immibis 2y ago
- mimasama 2y agoBesides, it will just end up being an xkcd 927, lol.
- robin_reala 2y agoThere was a reference implementation called Amaya.[1] It died, because the set of web standards is vast and sprawling, and without a business model implementing them has been seen historically as overly expensive. In the absence of a reference implementation, the only other suggestion for consolidation is to take an existing implementation and crown that as the winner. The problem is that implementation, regardless of open source, remains under the control of its altruistic parent company. That company then effectively gains sole control over the direction of the web, which we typically agree is a bad thing. The web is (and always has been) bigger than one engine. [1] https://en.wikipedia.org/wiki/Amaya_(web_editor) https://en.wikipedia.org/wiki/Amaya_(web_editor)
- mrweasel 2y agoThe issue is that if someone found a major issue in Blink, would it even be feasible to get every Chrome, Brave, Edge and Vivaldi user to switch to Firefox while the issue is fixed? The argument is still the same as with OpenSSH and OpenSSL. Having a single dominant code base is a security risk. The risk of OpenSSL has been realized and we now have good alternatives. OpenSSH have alternatives, but we're one major security issue away from having to shutdown remote management for potentially days. If anything we need even more browser engines, Blink is 90% or more of the market. Ideally no engine would be more than 20% of all users. Personally I still think it's worth it to have multiple engines, both for security, but also to ensure that enough people maintain the skills to keep development active. Or if the US government forces Google to sell Chrome, then there's no guarantee that the buyer would spend the same resource on Blink as Google does. Now I'm all for slowing down browser development (allowing alternative engines to develop and give web technologies a chance to settle down a bit) but with the wrong buyer it not only slows down, it stops, IE6 style. Having WebKit, Gecko, and more, helps push things forward in that case.
- ForTheKidz 2y agoFor those as confused as I, Blink is the webkit fork that powers the chromium-style browsers. Sort of like chrome's gecko.
- anonym29 2y agoWhat's the alternative? Threatening Gecko developers or contributors into quitting their work on Gecko and demanding they work on Blink or WebKit instead? Some of us passionately hate Google and Apple for their unethical business practices and would rather cease OSS contributions altogether than contribute to these tyrants.