Comment by esprehn | Hacker News Reader

Comment by esprehn | Hacker News Reader

Engine diversity is really important for the ecosystem and continued innovation. While building something competitive with the big three engines is a monumental task there's still a lot of value in building alternative engines to try new ideas even if getting "the whole web" implemented is basically impossible.

For example:

- Servo vs Blink vs Cobalt do selector matching and style resolution very differently.

- WebKit has a selector JIT, no one else does though.

- WebKit and Blink do layout super differently (with LayoutNG shipped).

- Firefox's html parser is written in Java and converted to C++ at build time.

The big value in folks trying to write new engines is finding these alternate paths. We can't depend on the big three for all the innovation.

That's what's great about Ladybird. Sure it'll need a lot of sophisticated sandbox improvements to get us to a big four situation, but it's more likely its value will be in finding another road the other engines didn't travel across the huge universe of specs, content and features.

But none of those differences are especially interesting. They certainly don't matter much for the ecosystem, and have no impact on web developers. All the major engines have comparable performance. And the differences are dwarfed by what they must do the same, because the way web tech works basically only allows one implementation architecture.

If you wanted to innovate in browser tech you'd really need to leave the specs behind. SCIter is an example of such an engine. It exposes APIs that are useful for app devs but that regular browsers don't have, for example it provides the vdom diffing algorithm React uses but implemented natively.

Even better if your browser can go beyond HTML and enable fully different ways to do apps and documents. That's the only place where design decisions can start to have a big impact.

> If you wanted to innovate in browser tech you'd really need to leave the specs behind.

This is pretty much what the author is suggesting by the end the article: "Instead of being a Web browser, you might want to initially try just being a faster, lighter or lower-power Electron or WebView. Then the Web compatibility barrier would be much less of an issue."

"- Firefox's html parser is written in Java and converted to C++ at build time."

This is surprising. Is it really true in the sense that the code that parses the HTML in a regular Firefox install was autoconverted when it was built?

Yep: https://searchfox.org/mozilla-central/source/parser/html/jav...

And more info: https://about.validator.nu/htmlparser/

Doesn't GWT transpile to Javascript?

Yes, that sentence is stating two different things:

> The parser core compiles on Google Web Toolkit *and* can be automatically translated into C++

Then I don't understand why GWT was mentioned. Does compiling on GWT have anything to do with the finished C++ code?

Huh, I was curious about how that was done, and it looks like it's a specialized Java to C++ converter: https://github.com/validator/htmlparser/blob/master/translat....

Looking at the source, it seems pretty easy to find Java programs that wouldn't compile correctly, but of course a fully general Java to C++ converter would be a huge undertaking. I guess with OK test coverage of the generated C++ code (which Firefox certainly has), editing the Java code remains doable.

Diversity alone is great but not quite enough. The alternative browsers need to actually see significant usage. Otherwise the developers and corporations will go "this browser has 99% market share so I can just ignore the others", giving the dominant browser makers enormous leverage over the others.

Reply on news.ycombinator.com