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

151–160 of 349 posts

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

#151

Post by cudgy »

asimpletune wrote: post #95
qikInNdOutReply wrote: post #88

Earlier quoted context omitted.

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.

It’s neither. There’s no management or promotions or really any incentive to do this other than it’s fun. It’s also not an architectural decision, just how they as a team decide what to work on.

But how does developing a half-baked browser that targets some websites for fun refute that building a browser is impossible? Doesn’t it provide another example that it is impossible, at least for this team?

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

#152

Post by arp242 »

Devasta wrote: post #85
vermilingua wrote: post #80

Earlier quoted context omitted.

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.

It's not clear to me if those are due to shortcomings in WebKit, the site, or if it's to be "bug-compatible" with anything else. Either way, 1,600 lines of code doesn't seem a lot to me.

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

#153

Post by chrismorgan »

tzekid wrote: post #115
monooso wrote: post #57

Earlier quoted context omitted.

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

I do mostly Python on my dayjob, but for low-level side-projects I've gotta say C++ with the C++17 or C++20 standard it's way faster to iterate with than say Rust or even something like Zig. For me iteration speed's a big selling point that (plus the fact that's easier to find contributors) might also be important for projects like these.

I’m puzzled by your comment. I am expert in Rust for almost a decade, but only mildly conversant in C++, and have no interest in actively learning more C++.

Rust seems to me far easier to learn and get going in due in major part to its incontrovertibly superior standard tooling.

I can’t see any place for any meaningful difference in iteration speed between the two, save that you may well have to iterate more in C++ due to memory safety bugs the compiler doesn’t catch.

As for finding contributors, I get the impression that Rust is considerably more accessible, and thus will increasingly find contributors more easily, as people that just love programming will actively choose to learn Rust far more often than C++. (For the current state of affairs, I think it’ll depend on what sort of contributor you’re looking for, in skill, industry, paidness, &c. Some segments will certainly go one way, and others certainly the other.)

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

#154

Post by simonw »

poisonborz wrote: post #68

Did he really wrote "having an experienced leader (me)" as one of the points.

He's clearly earned that title. He demonstrably has the experience - and inspiring and coordinating volunteer contributions to a project of this scale is an extraordinarily difficult leadership challenge.

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

#155

Post by arp242 »

rob74 wrote: post #137
chrismorgan wrote: post #126

Earlier quoted context omitted.

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

I did a quick check, and most of the errors it reports are "unknown attribute" or "element such-and-such not allowed here". Those "errors" would be allowed anyway for forward compatibility, and aren't really a big deal.

IMO the validator's definition of "invalid HTML" is just too strict; it should only count parse errors and completely non-sensible things. And the specification is also too strict at times; on my own website I have "Element style not allowed as child of element div in this context." This is because on some pages it adds a few rules that apply only to that page and this is easiest with Jekyll. I suppose I could hack around things to "properly" insert it in the head, but this works for all browsers and has for decades and why shouldn't it, so why bother?

If the specification doesn't match reality, then maybe the specification should change...

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

#156

Post by ilyt »

actionfromafar wrote: post #72
pavlov wrote: 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.

Depends on if your actual goal was getting twitter to work. If Twitter rendered fine, chances are some other site render fine today. The same it was with Wine.

Sure but Wine is a tool where if 90% of the stuff user wants to run in it works, it's still great. Say if you use it for gaming you can play most of the games and only boot into windows every few months once you hit one you can't.

But that's not how you use web. If 90% of the pages worked in browser I wouldn't use that browser, ever, because chances are I'd hit one that didn't at least once every few days.

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

#157

Post by muyuu »

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.

yep, even better in unmaintained consoles, where the popular demand for concrete binaries is pretty much set in stone and you can even aim to complete the entire library of software binaries over time - as they're usually in the hundreds or low thousands rather than millions or billions

however the aim to build a reasonably sized and not ossified-to-previous-spec web browser is very interesting, especially if it's well engineered and made to be portable

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

#158

Post by forgotpwd16 »

arp242 wrote: post #142
forgotpwd16 wrote: post #114

Earlier quoted context omitted.

>I mentioned this at the time And Drew himself answered you at the time on points made to your comment, that is things you said shouldn't be included that should and others you said were incorrectly included but were instead excluded in first place.

Those replies are handwavy and offer no convincing defence at all. In just a few minutes I was able to reduce the 1,217 URLs to 434 by simply excluding outdated or non-applicable stuff. That's about a third and includes some pretty large documents, and that's just with a quick check. The list is unambiguously categorically wrong and anyone who seriously looks at it and comes to a different conclusion is suffering fro…

>I was able to reduce the 1,217 URLs to 434

Why not post this list for the rest of us to see (and check) then? But beforehand those "outdated" stuff (such as your HTML 3.1 example) may still be applicable and excluding them means your approach is incorrect right off the bat.

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

#159

Post by illiarian »

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

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.

Post reply on HN