That's my point. The web is so complex that browser engines are becoming a monoculture. Even if you forked Chromium now, you'd need hundreds of engineers just to keep up with all the new things that are constantly added.

Yeah, I was rather sad to see EdgeHTML go. Although I never used Edge, rendering engine diversity is good for the ecosystem.

And yet the fact that the major engine implementation is opensource still allows each vendor to innovate by adding new useful features to the users.

We're really far from IE6 era of complete stagnation.

Not really, as far as the core browser engine tech goes. In practice it's too difficult to maintain a Chromium fork that diverges in any significant way other than the front end. Opera and Edge (per announcement) use vanilla upstream Blink.

> new things that are constantly added

By golly, that's the problem right there.

One thing I’ve discovered from learning and using Common Lisp seriously is that it’s really important for a system to be specified in a way that allows for extensions to the system to be implemented in terms of primitives the language provides (e.g. you want a new language construct, write a macro to transform your desired syntax into Common Lisp). In languages and systems that don’t have this feature, an implementation that introduces useful extension begins to develop lock-in and makes it harder to compete. (E.g. no one writes the Haskell specified in the Haskell report anymore, because all the libraries you might want to use use one or more ghc-specific extensions.( )

There are significant tradeoffs between shared constructs and self contained systems. Self contained systems resist ossification; they can be unilaterally replaced. A shared construct has to evolve in step with all of its users.

But the self contained system will have thousands of incompatible implementations, and the shared system will be easier to interact with and build on top of.

What this means is that a browser should standardize on things meant to be interfaces, and leave out all of the rest. Unfortunately, they didn't and now browser engines are huge and impossible to evolve except by adding more stuff.

Similarly, the value of programming languages is almost entirely in the interfaces they provide which allow you to develop code. Lisp provides almost none of that, and that is why it failed to become mainstream.

> no one writes the Haskell specified in the Haskell report anymore, because all the libraries you might want to use use one or more ghc-specific extensions

This is a bit of a misconception. One can still write Haskell98 whilst using a library that use a GHC-specific extension. The library doesn't (have to) force its consumers to use extensions too!

I phrased that a bit wrong: my experience (from talking to the Haskellers in my company) is that Haskellers generally prefer to turn on a bunch of extensions when they write code. So, while you might be able to write pure Haskell98, it tends not to be idiomatic to do so.

But since when is it a good thing that the last time someone managed to build a web render engine from scratch was thousands of years ago?

Hopefully Mozilla will have some luck modernizing by replacing pieces one at a time with Rust components. ;)

What do Firefox implementation details have to do with this?

They are modernizing the browser by replacing pieces over time. That's relevant to the topic of browsers being built on legacy tech.

I don't see how this supports to the argument that you can easily build a new, competing browser by forking. If you fork and then need the same kind of resources to replyce the forked codebase with your own, I don't see what you'd win.

Even if you fork, you'll still need constant investment to just keep it up-to date with the ever-evolving "living standard".