3 ms·
The WHATWG approach is not without its downsides, even setting aside the ideological points (e.g. that with no fixed releases you can never be done in any sense
by mananaysiempre 3y ago
The WHATWG approach is not without its downsides, even setting aside the ideological points (e.g. that with no fixed releases you can never be done in any sense):
The spec is good and makes you life easy (well, as not-tremendously-difficult as it could ever be) if you go with the LibWeb/Ladybird approach of transcribing it into code line by line; then there is a yawning abyss of performance engineering and conformance bugs a mile wide; then there are all other real implementations, which do not follow the spec word for word for reasons of efficiency. There are a myriad ways to do an LL(1) parser, all well-known to be equivalent; but you are on the hook for proving the validity of every little discrepancy with the WHATWG algorithm that you’ve had to introduce for one reason or another.
- olliej 3y agoSpeaking as a person who has implemented numerous web specs, you generally do start with a close approximation to the actual spec - I believe my original Map/Set implementations in JSC were exactly that. Once you have a complete and correct implementation, then you can actually measure things and work out the critical parts and make them perform reasonable well. But it’s really hard to do perf work if you don’t already have a reference/known good implementation. And that’s what LibWeb is doing, which is giving them a workable baseline. Certainly enough that I’ve seen a few Kling videos where he abLe to focus on perf issues. A lot of the core performance bottlenecks devolve to “cache more”, and then devolves to those most hallowed of problems: cache invalidation.