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

261–270 of 349 posts

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

#261

Post by mort96 »

nicoburns wrote: post #252
riffraff wrote: post #232

Earlier quoted context omitted.

Mozilla's servo seemed to be done in this fashion, so that some components were later brought to gecko/Firefox, so presumably you can do it.

Yeah, I think servo had the right idea. The main problem with servo's components is that they're severely underdocumented, which has made it harder than it should be for some components (like webrender) to become widely adopted (some of the other ones like html5ever and cssparser are widely used).

I suppose it depends on what the goal was. If the goal was to end up with widely reusable web browser components, the lack of documentation might've been a problem; but if the goal was to improve Firefox, it seems to have been a smashing success.

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

#262

Post by missblit »

hnlmorg wrote: post #69
tester756 wrote: post #4

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…

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

A 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.

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

#263

Post by cxr »

illiarian wrote: post #234
cxr wrote: post #221

Earlier quoted context omitted.

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

And yet, it's a decent proxy. That, and the number of specs required (many of whom are locked behind IEEE, IEC etc. paywalls)

Uh, no. It's a bad proxy, for the reasons just stated. As the spec gets more detailed, it gets easier to implement, not harder.

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

#264

Post by mardifoufs »

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…

How do you even start implementimg such a spec? I know it's probably a dumb question but how would one structure their code to check all those boxes? Does it usually involve reading the entire spec, then figuring out the foundational parts and building from there? Does that work when you need multiple specs to "fit" together? How do you make sure or even check that some code you built for some part of the spec does not interfere with something else?

I implemented a few specs in my short career but nothing even close to that. It's actually mind boggling that we manage to have all those moving parts fit together.

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

#265

Post by naikrovek »

pavlov wrote: post #62
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…

This approach works better for Wine where the Windows binaries are a fixed target. On the web, you may get Twitter's feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don't have and everything is totally broken again.

> On the web, you may get Twitter's feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don't have and everything is totally broken again.

this is not directed at you, but at this attitude which is very common and which I see all the time: everyone is lightning fast to come up with reasons that something won't work.

why?

why do people say things without understanding that almost any given problem has subproblems, and that those can be solved.

in humans, negativity is always just under the surface, and positivity is often buried deeply, and I do not understand this. I don't think I ever will. people just love to be contrarians.

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

#266

Post by illiarian »

gizmo wrote: post #248
illiarian wrote: post #242

Earlier quoted context omitted.

> features introduced today are much more carefully defined than the ad-hoc features of yesteryear. Many of them are just as ad-hoc, even if they are better defined, and meant to cover some holes in previous ad-hoc specifications. For example, the entire `subgrid` spec is patching one specific hole which actually has a proper general definition: "These however are independent of the parent and of each other, meaning…

What is harder, starting with nothing and building the equivalent of 2020 Chromium from scratch, or taking Chromium from 2020 and extending it with the new features to get it up to date with today's Chromium? The former is 100x harder than the latter, and the prior statement that new CSS/JS features are a burden to keep up with is patently absurd. Because it's a tiny amount of work relative to the total work required…

> the prior statement that new CSS/JS features are a burden to keep up with is patently absurd.

Chrome ships up to 400 new APIs a year (that is JS, CSS etc.)

Safari and Firefox ship 150 to 200 new APIs a year. [1]

Even Microsoft gave up on trying to keep up with browser development and switched to Chromium.

> Because it's a tiny amount of work relative to the total work required to make a browser.

That is, like, the primary work required. And many of those things often don't even have a solution until someone finally figures them out in a performant manner (like CSS's :has)

[1] https://web-confluence.appspot.com/#!/confluence

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

#267

Post by cxr »

illiarian wrote: post #229
cxr wrote: post #206

Earlier quoted context omitted.

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.

The only bar that the heuristic has to pass here is "delivers a result that doesn't suck as bad as the analysis in Reckless, Infinite Scope". The analysis in that article is so bad, however, that your heuristic can literally be, "if you encounter an item that was also in Drew DeVault's input set, then assign an arbitrary probability 0.9 (or whatever) of whether the item should be counted", and it would still give you a more realistic result than what the article says (and that people are actually relying on in their arguments—and that you are defending) here.

Aside from that, given how many logical errors and weird counterconclusions[1] you've managed to stuff into this discussion, though (and to have been able to do so economically[2]), I'm going to go ahead and say this is my last response to you that I spend more than 10 seconds writing out.

1. e.g. https://news.ycombinator.com/item?id=35521704#35524952>

2. wrt number of words, fittingly

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

#269

Post by F3nd0 »

ryanjshaw wrote: post #15

What we all REALLY care about: they went with C++ and Qt https://github.com/SerenityOS/serenity/tree/master/Ladybird

I care more about the choice of licence… and sadly enough, they went with a pushover/permissive one. This seems like the kind of project where copyleft is by far the better choice.

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

#270

Post by tabtab »

Since there's already plenty of HTML browsers, instead explore an unserved need, such as a stateful GUI markup browser & standard. HTML/DOM is missing many expected GUI idioms, and has an inherent text positioning flaw:

https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...

GUI's, desktops, and mice are still needed for biz and productivity. HTML browsers have been a goofy mess for this, requiring bloated buggy JS libraries with long learning curves. Let's Make Gui's Great Again! (No, I'm not a Don fan, BTW, but his trollisms are catchy.)

Post reply on HN