Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

awesomekling.substack.com

Post reply on HN
Print view View original

221–230 of 349 posts

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

#221

Post by cxr »

chrismorgan wrote: post #176
illiarian wrote: post #159

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.

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…

To underscore something that might get lost in the wall:

The entire premise given in Reckless, Infinite Scope is that the number of words in the specification is positively correlated with the intractability of implementing a given thing. From this foregone conclusion, it tries to quantify how much worse the task of implementing a Web browser is. The problem is that that the premise is a bad one; even if it takes more time to read a wordier spec, it is easier to implement one that describes well-defined behavior than a terse one that glosses over things and leaves huge gaps of undefined behavior. This is not just conjecture—it tracks with the development and progress of implementing, say, the HTML parsing algorithm; it is easier to implement a correct and acceptable HTML reader in 2023 armed with only the spec than it was to try to do the same thing in 2003 which involved reading the spec and also reverse engineering how other (esp. proprietary) browsers deal with the pages that you find authors actually publishing in the wild. This is a task that was made easier because the standard got bigger.

The point is that its broken methodology doesn't even matter; we don't have to try to come up with better ways of evaluating whether a spec should be included or not because its whole premise is flawed to begin with. Any attempt to produce an input set that you can then use to run a word count analysis is a moot academic exercise at best that will only tell you how many words it contains.

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

#222

Post by paulryanrogers »

ludston wrote: post #164
cudgy wrote: post #151

Earlier quoted context omitted.

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?

Doesn't that depend on whether or not they end up making a browser in the end?

Where is the end? And why claim you're doing the impossible until it's done?

It all comes off as puffery to me. Though the vertical slices approach is interesting, so I salute their efforts.

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

#223

Post by jssfr »

arp242 wrote: post #201
hanselot wrote: post #193

Earlier quoted context omitted.

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/

The Compliance Suites (also linked on the top of the page you linked) are intended to provide some guidance about what's important.

The current edition of those can be found in XEP-0459: https://xmpp.org/extensions/xep-0459.html

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

#224

Post by cubefox »

This post doesn't give reasons to doubt that building a new state of the art browser is basically impossible now. It might well be possible to build a new browser that kind of works on many popular websites, and that would be surprising enough. But the amount of work needed to build something comparative to the rendering engines of Chrome, Firefox, or Safari, something really usable, would probably take decades rather than years. If it is possible to catch up at all. (I remember once seeing a graph which compared software projects by lines of code, and browsers were only topped by a few things like major operating systems.)

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

#225

Post by yodsanklai »

cubefox wrote: post #224

This post doesn't give reasons to doubt that building a new state of the art browser is basically impossible now. It might well be possible to build a new browser that kind of works on many popular websites, and that would be surprising enough. But the amount of work needed to build something comparative to the rendering engines of Chrome, Firefox, or Safari, something really usable, would probably take decades rathe…

Is all the complexity of a browser in the rendering engine? can a browser be split into several components so that they can be rewritten concurrently?

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

#226

Post by Koffiepoeder »

ClawsOnPaws wrote: post #196
chrismorgan wrote: post #153

Earlier quoted context omitted.

I’m puzzled by your comment. I am expert in Rust for almost a decade, but only mildly conversant in C++, and have no interest in actively learning more C++. Rust seems to me far easier to learn and get going in due in major part to its incontrovertibly superior standard tooling. I can’t see any place for any meaningful difference in iteration speed between the two, save that you may well have to iterate more in C++ d…

I have a hard time deciding where in this thread to drop this link, but maybe here is a good spot. Andreas has a video about this topic, and I believe it's this one: https://www.youtube.com/watch?v=vAZvTFoSIFU

Published on April 1st 2022 ;-)

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

#227

Post by bob1029 »

lysecret wrote: post #212

This is exactly the type of thing why I am so excited about LLMs. If they make use widely more productive we can build huge things like this and take on the monopolies in the space. It might lead to a wave of "thought impossible to build" products.

I've been wondering if at some point we could eventually train the models in first-order terms. I.e. input some HTML/JS/CSS + user state (i.e. scroll position, x/y dimensions) and then it outputs a final rasterized frame representing the current state of the viewport. The training data would be fairly obvious and easy to collect.

Failing that, an optimized binary blob that could achieve the same using training data over modern browser specifications. If you go to ChatGPT and start talking about ISO32000-compliant implementations and poke at the edges, you can get it to start writing a PDF engine pretty quickly.

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

#228

Post by [deleted] »

ohgodplsno wrote: post #186
yellowapple wrote: post #53

> So instead of [building the browser one feature/spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives. Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the…

>Console emulators (especially of the HLE variety) seem to have a similar flow. And emulators that have gone this path have all regretted it, because they end up making hacks to make work, because everyone simply wants to play . Dolphin is still paying the price of that method years down the line. Project64 took years to unfuck themselves up, ZSNES is forgotten and overtaken by many more that have done the proper thi…

[deleted]

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

#229

Post by illiarian »

cxr wrote: post #206
illiarian wrote: post #199

Earlier quoted context omitted.

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.

> It is possible, and that sentence is verging on nonsense.

Define "reasonable" then, when talking about the web.

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

#230

Post by illiarian »

mananaysiempre wrote: post #211
illiarian wrote: post #194

Earlier quoted context omitted.

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

ISO 646 and 61966? I won’t disagree with your annoyance with ISO water torture[1], but ASCII and sRGB are not the examples of needlessly sprawling web of references I would’ve chosen. Even if sRGB is an utter mess[2], it’s a mess you essentially have to use if you’re doing colour on computers. [1] https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt [2] https://photosauce.net/blog/post/what-makes-srgb-a-special-…

I just randomly selected some without going too deep into details. But yes, sRGB is also referenced from CSS because, you guessed it, CSS deals with color :)
Post reply on HN