Regardless of actual use as an (embedded) browser, it is useful in the sense that it can be used to provide (another) source of validation about whether specs and WPT [1] tests are properly and clearly defined. That helps for long term browser compatibility.
Making a new browser engine hurts browser compatibility more than it helps it. It now becomes one more target that needs to be tested against, limitations need to be kept tracked of, etc. The best thing for long term browser compatibility is focusing resources into Blink. In regards to the standard we can use LLMs to cross reference the spec, with tests, and with the implementation to make sure all match.
yeah in a perfect world google dictates how the standard will evolve, we kill all competition so we're sure that you have only one target to build your software against, I'm sure a monopoly will greatly improves innovation and not be used to stiffen competition. /s
It's easier maintaining a fork of Blink than an entirely different engine. Google being the primary maintainer doesn't mean that browsers can't make large forks.
>work on other browser engines is not duplicated or wasted.
How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
> It's easier maintaining a fork of Blink than an entirely different engine. Google being the primary maintainer doesn't mean that browsers can't make large forks.
Maintaining a fork is not fun as taking patches from the origin repo becomes more complicated the longer the fork exists and the bigger the divergence becomes.
> How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
It would be duplicated only if they all maintained, say, a Blink fork.
p-e-w · · focus · HN ↗
It’s apparently still not ready to be used as a browser engine (and may never be), so what exactly is it for?
foresterre · · focus · HN ↗
[1] <a href="https://wpt.fyi/results/?label=experimental&label=master&product=servo&aligned" rel="nofollow">https://wpt.fyi/results/?label=experimental&label=master&pro...
charcircuit · · focus · HN ↗
Making a new browser engine hurts browser compatibility more than it helps it. It now becomes one more target that needs to be tested against, limitations need to be kept tracked of, etc. The best thing for long term browser compatibility is focusing resources into Blink. In regards to the standard we can use LLMs to cross reference the spec, with tests, and with the implementation to make sure all match.
Oxodao · · focus · HN ↗
charcircuit · · focus · HN ↗
samus · · focus · HN ↗
charcircuit · · focus · HN ↗
>work on other browser engines is not duplicated or wasted.
How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
samus · · focus · HN ↗
Maintaining a fork is not fun as taking patches from the origin repo becomes more complicated the longer the fork exists and the bigger the divergence becomes.
> How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
It would be duplicated only if they all maintained, say, a Blink fork.
kryptiskt · · focus · HN ↗
charcircuit · · focus · HN ↗
armadyl · · focus · HN ↗
Yet somehow this argument seems to evaporate since people’s brains short circuit the moment they see the name Google.
The community can always fork and maintain a separate version of Chromium if necessary. Or does this concept only not apply to Chromium?