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

Post by jonfw » Tue, Apr 11, 2023, 5:36 PM UTC

ohgodplsno wrote: post #297

troad wrote: post #272

Earlier quoted context omitted.

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

Post by hnlmorg » Tue, Apr 11, 2023, 5:41 PM UTC

missblit wrote: post #262

hnlmorg wrote: post #69

Earlier quoted context omitted.

A few reasons it’s harder to build a browser: - the web is numerous specifications: HTTP, HTML, CSS, JS, SVG. At worst, a regular compiler needs to worry about macros and the language syntax - each of those specifications has numerous versions which, in some cases, can be significantly different from other versions of the same language or protocol. A language compiler generally only focuses on one version of that lan…

A browser rendering engine's output isn't purely graphical, and most things can be tested through other means such as by reading console.log output, looking at the DOM, or looking at computed CSS styles and/or bounding-box information. In fact there's a good reason to keep graphical tests to a minimum: web specs do not dictate things down to the pixel level, so pixels can shift around from version to version, requiri…

Post by GaggiX » Tue, Apr 11, 2023, 5:45 PM UTC

kylieee wrote: post #292

GaggiX wrote: post #241

Earlier quoted context omitted.

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.

Post by kylieee » Tue, Apr 11, 2023, 5:48 PM UTC

GaggiX wrote: post #305

kylieee wrote: post #292

Earlier quoted context omitted.

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

By removing segmentation fault crash you have removed a large portion of unwanted crashes, the end result is very different.

Post by com2kid » Tue, Apr 11, 2023, 5:59 PM UTC

ohgodplsno wrote: post #186

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…

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