Re:Ladybird, the from-scratch SerenityOS browser, can now di...
by olliej on Monday November 07, 2022 @06:55PM
(#33514264)
Not really - there are certainly more of them, but - and this is extremely important - Mozilla, Apple, Google, and even MS spent the best part of a decade essentially rewriting the specifications that made up the web platform.
The DOM, etc through the work that eventually got labeled HTML5 made it possible to follow the spec and, as a super simple and "obvious" example, parse URLs in a way that worked. The existing specs of the era were often incomplete, semi-frequently what they did say did not match how browsers actually worked, and frequently ambiguous which meant that implementing anything required exhaustively testing what everyone else did to try and match it.
TC39 eventually recognized that the same issues existed in the ECMAScript spec, and recognized that ES4 did nothing to resolve those issues, while adding considerable complexity and more of the same issues. That's how we ended up with ES3.1 - it was an attempt to actually correctly and completely specify the language and runtime, ES5 continued/finished that catchup (ES3.1 did not resolve all the issues) while adding a few important features, but was still in the "make it possible for someone to implement the spec and be confident that they could run anything any other engine could run".
So in the modern browser there are many more specs, but those specs are much easier to confidently implement as you can get basic working behaviour by essentially translating the spec language into your environment.
Making the resulting engine fast, memory efficient, etc is of course another thing entirely (although even that is aided by removing ambiguity in the specs as the lack of ambiguity means that you can actually write tests now).
The DOM, etc through the work that eventually got labeled HTML5 made it possible to follow the spec and, as a super simple and "obvious" example, parse URLs in a way that worked. The existing specs of the era were often incomplete, semi-frequently what they did say did not match how browsers actually worked, and frequently ambiguous which meant that implementing anything required exhaustively testing what everyone else did to try and match it.
TC39 eventually recognized that the same issues existed in the ECMAScript spec, and recognized that ES4 did nothing to resolve those issues, while adding considerable complexity and more of the same issues. That's how we ended up with ES3.1 - it was an attempt to actually correctly and completely specify the language and runtime, ES5 continued/finished that catchup (ES3.1 did not resolve all the issues) while adding a few important features, but was still in the "make it possible for someone to implement the spec and be confident that they could run anything any other engine could run".
So in the modern browser there are many more specs, but those specs are much easier to confidently implement as you can get basic working behaviour by essentially translating the spec language into your environment.
Making the resulting engine fast, memory efficient, etc is of course another thing entirely (although even that is aided by removing ambiguity in the specs as the lack of ambiguity means that you can actually write tests now).