4 ms·
A few reasons it’s harder to build a browser: - the web is numerous specifications: HTTP, HTML, CSS, JS, SVG. At worst, a regular compiler needs to worry about
by hnlmorg 4y ago
A few reasons it’s harder to build a browser:
- the web is numerous specifications: HTTP, HTML, CSS, JS, SVG. At worst, a regular compiler needs to worry about macros and the language syntax
- each of those specifications has numerous versions which, in some cases, can be significantly different from other versions of the same language or protocol. A language compiler generally only focuses on one version of that language
- A browser needs to support broken websites. A compiler only needs to fail gracefully
- A browsers output is graphical, which is much harder to unit test
In short, you’re dealing with a harder problem across a broader number of specifications. I would liken writing a browser more closely to writing a new graphical OS than writing a compiler.
(“Browser” here means “browser + engine et al” and not just a reskin of Chromium).
- missblit 4y agoA browser rendering engine's output isn't purely graphical, and most things can be tested through other means such as by reading console.log output, looking at the DOM, or looking at computed CSS styles and/or bounding-box information. In fact there's a good reason to keep graphical tests to a minimum: web specs do not dictate things down to the pixel level, so pixels can shift around from version to version, requiring the occasional golden data rebase. Fun aside: Chrome's test suite contains a font named ahem.ttf where (almost) every character is an identical black rectangle. This allows tests to include text without relying too much on the details of a particular font.
- hnlmorg 4y agoThe examples you’ve given of the non-graphical elements are describing the easy problems and I was describing the hard problems. Our two posts aren’t mutually exclusive.