Live data from Hacker News

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

awesomekling.substack.com

121–130 of 349 posts

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

#121

Earlier quoted context omitted.

Son what i'm hearing is that you're looking forward to browser-in-a-browser as if that's somehow not the most depressing trend I didn't know about

Happy to admit it's a crazy idea, and it's not something that I would want to see as a usual way to built sites. But for small areas of web apps where compatibility is difficult it does make sense. Google Docs used to be contenteditable based, but moved to a custom rendering engine. They are a large enough company to be able to invest in that. Small businesses aren't, and have to rely on content editable. Ladybird as…

"Google Docs used to be contenteditable based, but moved to a custom rendering engine."

Is THAT why you can't cut & paste with the mouse in google docs like you can on every other site? Take me back to the old way then please.

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

#122
post #51

Earlier quoted context omitted.

All this "quirks mode" stuff is part of the specification, no? It makes it all a bit more complex than it has to be, but I do believe it's specified. I'm not really sure if "you need to be bug-compatible" is still true; it probably was 15 years ago, but Chrome, Firefox, and WebKit tend to be pretty decent these days.

If anything, websites have become way less clean and invalid HTML. I remember people, including myself, putting W3C validator icons on websites. Rarely do I see any these days, because of all the invalid HTML and dynamically created websites. Maybe all the tags are closed nowadays, so maybe at least that. But which elements are used inside which other elements and whether they are semantically appropriately used is a…

Those badges regularly did not reflect reality.

Nowadays, HTML parsing is exhaustively defined in the form of a couple of state machines, so it’ll behave the same everywhere. It’s genuinely easy to implement perfectly (though it’ll still take a while because there is quite a bit of it).

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

#123

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…

To add context: Andreas Kling is building that browser on top of his own from scratch OS.

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

#124
post #23

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…

It’s the work of Google’s PR team, there’s no competition if everyone thinks making a browser is impossible, so don’t even try, ~wink wink I’m only half joking but I’m pretty sure there are some PR companies pushing “trends” on the behalf of big corps. It would be stupid and uncapitalist not too…

Chromium, blink, v8, etc are all open source. There are plenty of competitors who have their own browsers.

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

#125
post #37

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…

Most new compilers build on LLVM/GCC, no?

Go has its own compiler.

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

#126
post #90
post #67

Earlier quoted context omitted.

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/

“Invalid HTML” is completely irrelevant. HTML parsing is defined exhaustively; “parse errors” are purely “you probably made a mistake, but I’ll keep going” indications, and all browsers will do the same thing.

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

#128

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

The web is still a great place to build something and show it off to your friends

[deleted]

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

#130

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

that's not true because their architecture follows closely the spec, so it couldn't be any better
Post reply on HN