Live data from Hacker News

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

awesomekling.substack.com

201–210 of 349 posts

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

#201

Earlier quoted context omitted.

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.

Given that someone that needs to develop a browser probably needs to hunt and peck through all that trash to find the relevant bits of information, is it not actually more damning that such a vast quantity of irrelevant cruft exists? Is this not the corporate equivalent of creating a walled garden (perhaps not the right phrase here, gastric moat sounds more apt), by exhausting the resources of all that should choose…

Isn't that true for any system that's been around for a few decades? Try implementing XMPP; which XEPs do you pick? It's a long list.[1] Try implementing email: there's probably more RFCs to exclude than include at this point, and what do you need and what is optional?

[1]: https://xmpp.org/extensions/

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

#202

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…

The main reason it's difficult is because the output criteria seem properly defined but they actually aren't at all. Yeah it's "just" building some parsers and figuring out live updates, but you have to keep in mind that this is ~the internet~. People have been uploading broken, against spec, webpages since forever. Coding a web browser as a serious project (so not as a flight of fancy) borders on the impossible most…

This comment gets some pretty important fundamentals wrong.

> The real bugbear here is JS though, HTML and CSS are complex but workable. JS is an ever-moving target

What you characterize as "JS" is, in reality, more HTML and CSS than JS. JS is a language. The fact that all the behavioral details of the HTML and CSS objects and related host objects have bindings available to JS programs does not make those things "JS"...

Doing a new JS engine from scratch is an order of magnitude easier than doing a browser engine. It is directly analogous to the eminently tractable "building a compiler" problem that the other commenter mentioned.

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

#203
post #177

Earlier quoted context omitted.

> 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/

>> > 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/ Doesn't that sort of prove my point? I dunno if you've tried both SerenityOS and Redox - I have, and SerenityOS is just more complete and usable as a daily driver than Redox[1]. Redox developed over 7 years has less functionality than SerenityOS developed over 4 years.…

Sort of... but that could be due to a host of other factors besides which language is better: how good the core developer(s) are at community-building, how committed they themselves are to the project... hell, even the fact that one project used GitHub (which reduces the friction for developers who are already on GitHub to start working on the project), while the other one has its own GitLab might be relevant.

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

#204
post #151

Earlier quoted context omitted.

It’s neither. There’s no management or promotions or really any incentive to do this other than it’s fun. It’s also not an architectural decision, just how they as a team decide what to work on.

But how does developing a half-baked browser that targets some websites for fun refute that building a browser is impossible? Doesn’t it provide another example that it is impossible, at least for this team?

Well, it takes time to make something big. And, one way to do it is to choose end-to-end functionality. Idk, it doesn’t seem so controversial to me. I’d wait and see before calling it half-baked.

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

#205

Earlier quoted context omitted.

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…

> and I suspect it’s bigger than everything else put together, apart from ECMAScript The thing is, it's not just the HTML standard. It's also all the standards it references. And all the standards they reference, and all the standards those standards reference, ad infinitum. For example, HTML 5 references SVG 2 which references CSS 2 which references Unicode and XML 11 . Or, to go the same route, HTML 5 references SV…

Essentially any specification that includes any kind of image support will include this kind of chain of specifications; just as any system that does networking will eventually end up with TCP, any system that does text ends up with Unicode, etc. Even the simplest possible 1995-esque browser will have to deal with that (support for images was added in 1993, and text and networking were always central).

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

#206
post #175

Earlier quoted context omitted.

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…

It may not be possible to come up with a "reasonable heuristic": https://news.ycombinator.com/item?id=35524018

It is possible, and that sentence is verging on nonsense. A heuristic is not by definition perfect or optimal.

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

#207

I’m curious as to why on this

As with everything in Serenity - why not? It's fun and people are motivated to work on it. If that wasn't the case it wouldn't be a project.

And that's not meant to be a pithy response. That's the Serenity culture.

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

#208

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:…

Mozilla Windows binaries weight 226MB ... does it mean encoding rate of 2 bytes per word of specifications? Pretty good packing, I'd say.

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

#210

5000 feet up the mountain: "I'm climbing Everest solo without oxygen even though it's supposed to be impossible. How come I'm making such good progress?!"

I hope these guys do well, but yeah. In my lowly experience, the last 10% of the goal takes 90% of the time.
Post reply on HN