Live data from Hacker News

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

awesomekling.substack.com

281–290 of 349 posts

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

#281
post #62

Earlier quoted context omitted.

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…

It's really tiring. It's everywhere on HN, I deal with it everyday at work, and everywhere else I look.

Instead of it being criticism, the commenter could've seen it as a positive. Every time a site changes, you discover functionality you haven't implemented yet. Over time, you've implemented more and more. It's progress. Progress is good. Choosing the negative interpretation is so endemic and arbitrary and simply unnecessary.

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

#282

This is great. Refreshing to read something which talks about complexity as a real and important issue (not as a positive or neutral aspect of a system). I've been hoping for a browser like this since the day I tried to download the Chromium repo and found out how large it was. Also, I noticed that it had a large number of external dependencies which made it very difficult to actually dig into the code.

Modern HTML browsers have become Swiss Army Spaghetti. Perhaps we need to split the standard into smaller components so one size doesn't have to fit all. I suggest at least 3 sub-standards:

A) Document-oriented standard. Perhaps HTML standards are "good enough" for this?

B) Media/Art/Gaming.

C) Business & Data CRUD/GUI

(And don't link that XKCD cartoon about 15 standards. There are zero for these categories.)

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

#283

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…

A new browser does have some benefit of hindsight, but if I had to look at the Firefox source for it, I'm not even sure where I'd begin.

> browsers were only topped by a few things like major operating systems

And they're even closer once you subtract out things like device drivers.

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

#284
post #62

Earlier quoted context omitted.

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…

Can you imagine some situations where this strategy would have positive value?

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

#285
post #261

Earlier quoted context omitted.

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.

It has been good at improving Firefox, but if you look at the wider picture then you see that Firefox has been falling in usage and struggling to keep up with webkit/blink. And IMO a large part of that is because core parts of Firefox Gecko and Spidermonkey are much less widely used (by as many apps/companies) than equivalents like Webkit/Blink/V8/JSC, and this because they are not easily embeddedable and their codebases are harder to work with.

From this perspective, not focussing on documentation and making components usable externally is pretty short sighted.

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

#286
post #62

Earlier quoted context omitted.

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…

If you have infinite time and resources with perfect communication/understanding you can solve a lot of engineering problems. No one has that. This is where the original quoted claim from the article comes from, "building a web browser is impossible". That's encoding a lot of experience and reality of the Brobdingnagian challenge of building a web browser from scratch on 2023's web.

It's not negativity to point out a downside to an approach to a particular problem. It's potentially useful to get feedback on a development approach. Constructive criticism is very important in engineering projects because it encodes assumptions of limitations we all have.

A positive statement like "oh those sub problems are solvable!" doesn't really provide any help. No shit the problems are solvable in a perfect world. Such statements aren't even necessarily constructive because they don't offer any analysis or advice. It smacks of toxic positivity[0].

[0] https://en.wikipedia.org/wiki/Toxic_positivity

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

#287
Linus Groh of LibJS is an Invited Expert in TC39: https://linus.dev/posts/road-to-working-on-serenityos-and-la...

ECMAScript conformance test results looking good, 87-88% passing at the moment: https://libjs.dev/test262/

I see weekly summary articles about Ladybird development are now being published: https://linus.dev/posts

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

#288
post #263

Earlier quoted context omitted.

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.

A more detailed spec might have more concrete definitions but it also means more actual code for someone to write. An under-detailed spec you might have a case switch with a couple defined values and an undefined catch all. A super detailed spec just adds case statements and requires more code to handle them. The detail in the spec makes for lower cognitive load but the code still needs to be written and ideally tests written.

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

#289

Earlier quoted context omitted.

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

Can you imagine some situations where this strategy would have positive value?

It's just an effort to enforce social conformity. A specific case of this type of browbeating may not be helpful, but on the whole it's often positive for the group to be mostly uniform. It's also often negative! More a value-neutral standard human tribal grouping behavior than anything.

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

#290

I absolutely love that Andreas Kling doesn't care about it being hard/impossible, and just dives straight in with pure optimism. It's absolutely wonderful to see the joy and positivity.

There’s also the matter of him having worked on browsers before, so he’s not exactly flying blind.
Post reply on HN