Live data from Hacker News

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

awesomekling.substack.com

131–140 of 349 posts

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

#132
post #64

I think adoption and maintenance will be the hardest parts of the project.

It is irrelevant because popularity is not the goal of the project.

From Serenity OS page [0]:

> This is a system by us, for us, based on the things we like.

[0]: https://serenityos.org/

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

#133
post #61

Earlier quoted context omitted.

Firefox has tons and tons of C++ to this day.

Yes, but they are replacing it bit by bit - I mean, they even started Rust for exactly that purpose. So (without being a huge fan of Rust) the decision to start a "greenfield" browser project in a memory-unsafe language is questionable IMHO...

I think it was more like "they were" up to the point the Rust team got layed off.

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

#134
post #57

Earlier quoted context omitted.

Firefox has tons and tons of C++ to this day.

But would they choose C++ if they were _starting_ today?

Note that SerenityOS started in 2018, they decided to use C++ for it, and even the newly created language for safer userspace (Jakt) generates C++ as target.

So maybe, Jakt will get used as well.

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

#135
Since “The reckless, infinite scope of web browsers” is depicted at the start of the article, I think it’s worth pointing out that its claim of W3C having 1,217 specs totalling 114 million words is wildly wrong, probably by 2–3 orders of magnitude in the total. The considerable majority of the documents considered were not specs or not web-relevant, and dozens of versions of the same thing were often counted. Source: https://news.ycombinator.com/item?id=22617721.

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

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

One of the ideas behind HTML5 is that while there is some concept of validity and well-formedness, essentially any random stream bytes describes exactly one DOM tree, in some cases the resulting tree is surprising, but even then should be same across all conformant parsers (modulo scripting support).

The end result is that validation is not that much interesting anymore, because the idea was that valid (X)HTML document should parse the same accross all browsers (which it mostly did, but that did not say much about how it was actually rendered).

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

#137
post #90

Earlier quoted context omitted.

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.

And that's why we can't have nice things, er, why we will never have valid HTML on a significant percentage of websites: browsers are historically very lenient with HTML errors (because otherwise they wouldn't be able to show 90% of all sites), and no one uses HTML validators to check if their HTML actually conforms to the spec. It's a chicken and egg problem really: the browsers can't be more strict because there are so many broken sites, and the sites won't be fixed because the browsers aren't strict enough.

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

#138

The fact there are better specs doesn’t help if a large part of the work is handling things that are outside the spec. You better show every “buggy” page similar to how the major browsers show them or the new browser will be considered defective. That’s the unfortunate reality of web tech (I wish every page with an js error or incorrectky closed tag would be a big fat error message but it isn’t). And that’s still a l…

Yep, Opera 12 was the most standard complaint browser when it existed, and it died

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

#140
I wish there was a auto-migration framework, if one software product like my browser is corrupted aka sells out, it packs my settings into a neutral interface file and automatically migrates to a still untouched browser or offers me a list to chose from. Like Nomadic herds of animals, hunted by predators, ever elusive, never caught..
Post reply on HN