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

291–300 of 349 posts

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

#291

Post by sublinear »

ilyt wrote: post #156
actionfromafar wrote: post #72

Earlier quoted context omitted.

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.

I completely agree. The people advocating for this type of development style are in another universe. Web is incredibly fragile.

There's a vast difference between a page being degraded by all browsers in a consistent manner per W3C specs (especially the critical parts of a webpage such as JS execution or malformed HTML) vs the damn thing breaking in such a unique way that the web devs will never be able to fix the page for this new browser while getting it to work the same for others. Worst case would be security is compromised and that is a very long list of things to implement in both the HTTP layer and browser behavior before you even get started trying to render a page.

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

#292

Post by kylieee »

GaggiX wrote: post #241
bogwog wrote: post #200

Earlier quoted context omitted.

Can you recommend a language that doesn't crash?

Any language that enforces memory safety is unlikely to crash because of a segmentation fault.

They will instead crash because of an uncaught exception or a panic handler - end result is the same.

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

#293

Post by im3w1l »

arp242 wrote: post #201
hanselot wrote: post #193

Earlier quoted context omitted.

Given that someone that needs to develop a browser probably needs to hunt and peck through all that trash to find the relevant bits of information, is it not actually more damning that such a vast quantity of irrelevant cruft exists? Is this not the corporate equivalent of creating a walled garden (perhaps not the right phrase here, gastric moat sounds more apt), by exhausting the resources of all that should choose…

Isn't that true for any system that's been around for a few decades? Try implementing XMPP; which XEPs do you pick? It's a long list.[1] Try implementing email: there's probably more RFCs to exclude than include at this point, and what do you need and what is optional? [1]: https://xmpp.org/extensions/

This is in fact one of the big issues with xmpp. Everything is sorta-kinda compatible but not really. And email is so getting so complicated that many people are scared of running their own server let alone programming one.

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

#294

Post by Mavvie »

alex_lav wrote: post #280
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 is how most games are developed as well. https://www.whatgamesare.com/vertical-slice.html

I don't think that link supports your comment. It says that vertical slices (at least as described by that article) are generally unrealistic in game dev.

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

#296

Post by alex_lav »

Mavvie wrote: post #294
alex_lav wrote: post #280

Earlier quoted context omitted.

This is how most games are developed as well. https://www.whatgamesare.com/vertical-slice.html

I don't think that link supports your comment. It says that vertical slices (at least as described by that article) are generally unrealistic in game dev.

You're right! I skimmed the first paragraph, as I was mostly just looking for a description of vertical slices in games. The rest of the content does not in fact validate my statement.

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

#297

Post by ohgodplsno »

troad wrote: post #272
ohgodplsno wrote: post #186

Earlier quoted context omitted.

>Console emulators (especially of the HLE variety) seem to have a similar flow. And emulators that have gone this path have all regretted it, because they end up making hacks to make work, because everyone simply wants to play . Dolphin is still paying the price of that method years down the line. Project64 took years to unfuck themselves up, ZSNES is forgotten and overtaken by many more that have done the proper thi…

I feel like you may have misunderstood what kling is saying. He's not saying "we will cut any corner to get Twitter to load", he's saying "we look at what it would take to get Twitter to load, read through the relevant specs, and try our best to implement the required features cleanly and correctly". Loading Twitter (etc.) is not really the goal, it's more of a prioritisation mechanism for tackling a huge spec. Actua…

No, I understand what Andreas is saying. But the reality is, when you read and implement specs for a specific website, you end up cutting corners, even accidentally. Maybe Twitter relies on a particular behavior of fetch() that was screwed up in Chrome 97 and has had to be kept for backwards compat this entire time. Maybe it uses some CSS that never got properly documented or specified.

By targeting a single website, you end up accidentally writing in those site-specific fixes _in_ your implementation. You only realize it's fucked up because you visited Twitter. but maybe it screws up another site. Maybe something else depends on a quarter of that functionality, and you've accidentally broken it.

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

#298

Post by jeroenhd »

GaggiX wrote: post #112
eastbound wrote: post #35

Earlier quoted context omitted.

I thought unsafe language were a no-go in the context of extremely vulnerable pieces of software like the web?

The biggest problem IMO with using C++ when I tried the browser is that it crash, it crash a lot and I would imagine they are segmentation fault.

Last time I tried the browser, most crashes were the typical "not implemented yet" code paths. Some feature wasn't built yet, so necessary flags weren't set, so the program caught the invalid state and died.

I don't think I've ever seen a crash in either Serenity or Ladybird that I could attribute directly to memory management. For volunteer C++ projects, their memory management seems to have been done excellently. Using modern C++ features and things like error return types instead of null seems to be a key part in making the browser this good.

It's also worth mentioning that as far as I know Ladybird doesn't implement a JIT engine, using bytecode to execute Javascript instead. That should also make life significantly easier for memory management.

It's still a young browser and I'm sure there are some nasty memory corruption bugs lurking in the depths, but I haven't seen those yet.

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

#299

Post by jeroenhd »

bogwog wrote: post #200
GaggiX wrote: post #112

Earlier quoted context omitted.

The biggest problem IMO with using C++ when I tried the browser is that it crash, it crash a lot and I would imagine they are segmentation fault.

Can you recommend a language that doesn't crash?

There are some languages that can be formally verified, and have themselves been formally verified.

Formal verification is a complete pain in the ass to do and there's a reason it's mostly done only in the most critical of systems, but if a program passes 100% formal validation, you're as close to crash free as you can possibly be.

I believe Ada and some other lesser used language sport well supported formal verification methods. You won't be able to use C/C++/Java/Rust it you're going for 100% formal verification though. There are attempts to bring the concepts to more commonly used languages (Frama-C, for example) but in my experience they're stuck in PhD-ware hell, great for writing papers but terrible for writing actual software.

Post reply on HN