Live data from Hacker News

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

awesomekling.substack.com

81–90 of 349 posts

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

#81

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…

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

A conformant C++ compiler is in the same ballpark as a browser, but a naive C compiler is orders of magnitudes simpler.

Recreating the Windows OS is in the same ballpark as a browser, but a simple OS that boots and runs command-line apps is orders of magnitudes simpler.

People don't casually start new C++ compilers or projects such as WINE, but they do start toy compilers and OS all the time.

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

#82
honestly the web is so broken, i think it is beyond repair, i just want to run the website through some LLM to get the content out and show it in lynx and be done

i dont want to consent to be tracked, i dont want to login, i dont want a presonalized feed, i dont want to subscribe to your news letter, i dont want your ads, ethical or not

js is still an issue, but maybe a day will come when i can say to the model 'pretend you are js interpreter; what is text the output of this minified react garbage and show it as markdown' and just pipe it to lynx or w3m or worse case eww

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

#84
post #62

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

The point isn’t that “getting X to work” is a one-and-done job. Rather, you’re using major websites as indicators for what features to target next, because those are largely one-and-done.

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

#85
post #79

Earlier quoted context omitted.

Quitks mode is one thing, but most browsers have specific rules for specific websites, a manual process to update and handle those cases. Pretty sure chrome and safari have hundreds of these rules.

Do you have any references? I'd be interested to see the list and what workarounds are needed

https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...

Don't know if this is everything, but there are a bunch of specific websites mentioned in here.

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

#86

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…

Compilers aren't routinely built anew either, except for new languages. Browsers are rarely written around a new language. (if you did invent a new language substituting html+css+js you'd likely want to implement it on the existing stack first, kind of like an equivalent to "complies to C")

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

#87
post #67
post #33

Earlier quoted context omitted.

More specifically, Chrome used Safari's rendering engine, and Safari used Konqueror's rendering engine, because even in 2001, starting a browser engine from scratch seemed like too much work.

I would say that in 2001, starting a browser engine from scratch was more work than today, because (as other commenters have noted) since then the specifications have become more robust and the "tag soup" sites not following the specs have become fewer.

Today's HTML spec defines precisely what will happen for any input—feed modern browsers all the tag soup you'd like!

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

#88

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

Do we really pretend this is a architecture decision? This is the classic Agile Management wants to show result for reward fast, that leads to huge tech debt build up, as layers are not properly designed and reuseable.

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

#89
The specs really are drastically better than they used to be. Compare the modern specification for CSS Table Layout (https://www.w3.org/TR/css-tables-3/) with the older CSS2 one (https://www.w3.org/TR/CSS2/tables.html). The older one doesn't even attempt to define the "automatic layout algorithm" at all!

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

#90
post #67
post #33

Earlier quoted context omitted.

More specifically, Chrome used Safari's rendering engine, and Safari used Konqueror's rendering engine, because even in 2001, starting a browser engine from scratch seemed like too much work.

I would say that in 2001, starting a browser engine from scratch was more work than today, because (as other commenters have noted) since then the specifications have become more robust and the "tag soup" sites not following the specs have become fewer.

https://meiert.com/en/blog/valid-html-2021/

Most sites still don't have valid HTML.

EDIT: my link is old. 98% of the top 100 sites had invalid HTML in 2021, in 2022 we've managed to hit 100%, great job everyone!

https://meiert.com/en/blog/valid-html-2022/

Post reply on HN