Live data from Hacker News

We're building a browser when it's supposed to be impossible

awesomekling.substack.com

171–180 of 349 posts

Re: We're building a browser when it's supposed to be impossible

#171

I'm finding it weird that unlike other non-trivial projects like OSes or compilers, people often discourage building web browser engine because it is "hard" or something like that like... how is it different from building a compiler? You gotta build HTML parser, CSS parser, figure out a fancy structure to represent those concepts and modify at fly. Also there's difference between making it work and making state of th…

Big problem is the constant feature churn in the web space. Getting from zero to browser is probably doable. Staying at the mark with the ever shifting CSS standards and the constant deluge of web extensions is hard and expensive.

I don't think that's true at all. We get only a handful new CSS features every year, and features introduced today are much more carefully defined than the ad-hoc features of yesteryear. Implementing them is pretty straightforward. Certainly not more difficult than any of the million other things you have to do when building an OS from scratch.

The difficulty of building a state-of-the-art browser is almost entirely about performance. Everything else is straightforward by comparison.

Re: We're building a browser when it's supposed to be impossible

#173

Why not just fork Firefox?

I agree. Can someone explain why this is not a good solution?

> Also, since Ladybird is an offshoot from the SerenityOS project, it shares the same culture of accountability and self-reliance. We avoid 3rd party dependencies and build everything ourselves. In part because it’s fun, but also because it creates total accountability for what goes into our software.

From the article.

Re: We're building a browser when it's supposed to be impossible

#174
post #156

Earlier quoted context omitted.

Depends on if your actual goal was getting twitter to work. If Twitter rendered fine, chances are some other site render fine today. The same it was with Wine.

Sure but Wine is a tool where if 90% of the stuff user wants to run in it works, it's still great. Say if you use it for gaming you can play most of the games and only boot into windows every few months once you hit one you can't. But that's not how you use web. If 90% of the pages worked in browser I wouldn't use that browser, ever, because chances are I'd hit one that didn't at least once every few days.

> If 90% of the pages worked in browser I wouldn't use that browser, ever

They don't care.

Re: We're building a browser when it's supposed to be impossible

#175

Since “The reckless, infinite scope of web browsers” is depicted at the start of the article, I think it’s worth pointing out that its claim of W3C having 1,217 specs totalling 114 million words is wildly wrong, probably by 2–3 orders of magnitude in the total. The considerable majority of the documents considered were not specs or not web-relevant, and dozens of versions of the same thing were often counted. Source:…

Worth noting the discussion at the link. Given that he omitted huge specs like WebGL etc. I wouldn't say it's wildly wrong. But I'd love to somehow arrive at a better estimate.

It's not hard. Start with the WHATWG's spec, then incorporate the other specs it references using a reasonable heuristic to determine if a given item should be included or not.

If you don't think the estimate from Reckless, Infinite Scope is wildly off, then you either didn't read the methodology and do a spot-check of the dataset, or you really don't understand the scope of what gets published by W3C and how little much of it has to do with Web browsers or how many revisions of them there are.

Re: We're building a browser when it's supposed to be impossible

#176

Since “The reckless, infinite scope of web browsers” is depicted at the start of the article, I think it’s worth pointing out that its claim of W3C having 1,217 specs totalling 114 million words is wildly wrong, probably by 2–3 orders of magnitude in the total. The considerable majority of the documents considered were not specs or not web-relevant, and dozens of versions of the same thing were often counted. Source:…

Worth noting the discussion at the link. Given that he omitted huge specs like WebGL etc. I wouldn't say it's wildly wrong. But I'd love to somehow arrive at a better estimate.

I believe it’s still wildly wrong. Had arp242 not spoken up at that time, I’d have been saying something similar, because the numbers were to me blindingly obviously extremely unrealistic. The entire HTML Standard (which is somewhat of a misnomer now, it covers much more than just HTML, quite a bit of CSS interactions, other web platform functionality, JavaScript APIs, and the likes) is now about half a million words by the most generous of counting methods (it’s written in a fairly verbose style, which is a really really really good thing when you compare it to the average IETF RFC), and I suspect it’s bigger than everything else put together, apart from ECMAScript (around 270,000 words¹ and probably growing at a faster rate than all other specs: it’s written in an even more verbose style, most of which is effectively straight code in prose form, whereas in the HTML Standard “straight code” is only a decent chunk of it).

As for WebGL, the WebGL parts are actually quite little. https://registry.khronos.org/webgl/specs/latest/1.0/ is only about 20,000 words. I gather it defers significantly to GLES20 (PDF, 204 pages, ~60,000 words), and GLES20GLSL (PDF, 119 pages, ~30,000 words), and it has GL32CORE in its references (PDF, 404 pages, ~125,000 words), but doesn’t actually use cite it in the text and I don’t know if it’s relevant. There doesn’t look to be anything else significant that wouldn’t already be included.

But really, WebGL is a fairly thin layer atop OpenGL ES 2.0, just removing some functionality and applying some restrictions. I believe you would reasonably expect a browser to use an existing OpenGL ES 2.0 implementation, so I’d be quite content to exclude the 90,000 (or perhaps it’s ~215,000?) words of that, just like it’s common to reuse an existing JavaScript engine (though you also don’t have to). Yet note this: it seems that even if we include it all (and presuming I haven’t missed anything, which I admit I could easily have done, I’m not conversant with these specs like I am with HTML/CSS/JS specs), it’s still under 0.2% of Drew’s massively-inflated figure.

—⁂—

¹ Whew, https://262.ecma-international.org/ took me several minutes to download, despite being only 7MB. Sigh; the trials of being in Australia, where things hosted in the USA are often inexplicably painfully slow—like, sub-256kbps. When already downloaded, it renders in under four seconds, which is really fairly impressive when it’s doing all that layout on a document a million pixels tall—this ain’t a PDF where you can only render one page at a time. The HTML Standard is almost two million pixels tall, and also loads completely in under four seconds—simpler styles, perhaps? I refer to it often enough that I build it locally so I don’t have to download its 13MB all the time, or compromise with the multipage version that you can’t search through as easily.

Re: We're building a browser when it's supposed to be impossible

#177
post #61

Earlier quoted context omitted.

Yes, but they are replacing it bit by bit - I mean, they even started Rust for exactly that purpose. So (without being a huge fan of Rust) the decision to start a "greenfield" browser project in a memory-unsafe language is questionable IMHO...

> Yes, but they are replacing it bit by bit - I mean, they even started Rust for exactly that purpose. So (without being a huge fan of Rust) the decision to start a "greenfield" browser project in a memory-unsafe language is questionable IMHO... Maybe, but the speed with which SerenityOS, its programs and the browser has been implemented, with so few man-hours thrown at it kinda displays why C++ was chosen over Rust.…

> There is no comparable project in Rust that demonstrates just how quick you can go from "nothing" to Full-Fledged OS

https://www.redox-os.org/

Re: We're building a browser when it's supposed to be impossible

#178
post #78
post #61

Earlier quoted context omitted.

Yes, but they are replacing it bit by bit - I mean, they even started Rust for exactly that purpose. So (without being a huge fan of Rust) the decision to start a "greenfield" browser project in a memory-unsafe language is questionable IMHO...

It's not clear to me that they are replacing it bit-by-bit. https://4e6.github.io/firefox-lang-stats/ I don't have an over-time series, but if you're willing to take my memory at its word Rust's percentage has hovered at around 10% for a while now. It seems to have actually gone down recently. Combine that with efforts like Servo being wound down and their team being let go, and it makes me wonder what the future of…

This chart looks like it could use some filtering for what constitutes a language used to build Firefox. It seems questionable that HTML is used to build 16 % of it. I suspect that is a result of test cases being included in the chart as it is based off of the whole repo. I checked out the repository and it doesn't have the GitHub language bar I see on other repos, so I can't click the HTML bit in it to filter down the HTML files in the repo and see if they are mostly tests or not, but it is hard to imagine they would be anything else. Maybe bits of the browser Chrome but still, that wouldn't be a whole 16 % I think.

Re: We're building a browser when it's supposed to be impossible

#179
post #142

Earlier quoted context omitted.

Those replies are handwavy and offer no convincing defence at all. In just a few minutes I was able to reduce the 1,217 URLs to 434 by simply excluding outdated or non-applicable stuff. That's about a third and includes some pretty large documents, and that's just with a quick check. The list is unambiguously categorically wrong and anyone who seriously looks at it and comes to a different conclusion is suffering fro…

>I was able to reduce the 1,217 URLs to 434 Why not post this list for the rest of us to see (and check) then? But beforehand those "outdated" stuff (such as your HTML 3.1 example) may still be applicable and excluding them means your approach is incorrect right off the bat.

The HTML 3.1 specification is essentially irrelevant for implementing a modern browser; and you certainly don't need HTML 5.0, and, HTML 5.1, and HTML 5.2, and HTML 5.3, and, HTML 4.0, and, HTML 4.01, and, HTML 3.2, and, XHTML 1.0, and, XHTML 1.1, and, XHTML 2. These are large documents; possibly the largest in the set.

It takes a minute to spot-check; some specific examples were provided in the previous thread. I don't have the list any more and can't be bothered to recreate it; what value is there if you can just check Drew's list – which is really not that hard? I also have no idea how correct it is, exactly; I suspect the actual number would be even lower still.

Re: We're building a browser when it's supposed to be impossible

#180

Since “The reckless, infinite scope of web browsers” is depicted at the start of the article, I think it’s worth pointing out that its claim of W3C having 1,217 specs totalling 114 million words is wildly wrong, probably by 2–3 orders of magnitude in the total. The considerable majority of the documents considered were not specs or not web-relevant, and dozens of versions of the same thing were often counted. Source:…

> probably by 2–3 orders of magnitude

So the web is maybe only 1.2 specs with 114,000 words? I think it's considerably more than that. If that estimate is off, it's by no more than a factor of 10, IMO. No need to exaggerate.

Post reply on HN