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

271–280 of 349 posts

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

#271

Post by chrismorgan »

arp242 wrote: post #189
illiarian wrote: post #159

Earlier quoted context omitted.

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.

The question is what exactly is needed for a useful and functional browser. You certainly don't need all features from Chrome, but you do need more than, say, Lynx or Dillo. Is WebGL needed? I've browsed the web for years with it disabled and have not suffered any inconvenience. I'd probably say it's not needed, but I'm a bit on the fence about it and can understand if people would disagree. All browsers implement XS…

> I think most of the complexity stem not just from the word count, but rather that everything interacts with everything else.

And most specifically in layout and rendering. HTML, JavaScript and the parts of CSS that aren’t, y’know, doing anything, are all very straightforward, despite having the significant majority of the word count. If anything, I’d say that in web matters implementation difficulty is inversely proportional to word count, because its verbosity pretty consistently comes from precision (which makes implementation easy). Layout stuff would be much harder to define exhaustively in that fashion, nor is it done so in most places.

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

#272

Post by troad »

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…

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. Actually getting Twitter to run is a nice reward for all that hard work though, and a series of such rewards keeps the contributors motivated in the marathon that is building a browser.

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

#273

Post by [deleted] »

hanselot wrote: post #193
illiarian wrote: post #159

Earlier quoted context omitted.

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.

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…

[deleted]

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

#274

Post by tristan957 »

throwaway2037 wrote: post #218
codetrotter wrote: post #21

Earlier quoted context omitted.

The cross-platform version of the browser uses Qt The version of the browser native to SerenityOS hopefully still uses the SerenityOS GUI libraries

It looks like they ported Qt to SerenityOS. I saw a package called "qt6-serenity". Perhaps they use the SerenityOS GUI libraries underneath. Does anyone know?

Ladybird is a browser based on SerenityOS technologies that uses Qt as the GUI framework. In SerenityOS, they have their own browser using the same underlying technologies, but a different in-house GUI framework.

WebKit and Blink are similar in how they have their different counterparts like QtWebEngine or WebKitGTK. The equivalent to WebKit and Blink in SerenityOS is called LibWeb.

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

#275

Post by r3trohack3r »

selfhoster11 wrote: post #246
r3trohack3r wrote: post #48

Earlier quoted context omitted.

As an industry we’ve taken a long and windy path to delivering full applications (with a local cache) on every load to a sandboxed environment that is mostly compatible across environments. While it’s easy to take shots at the current state, I find it hard to imagine another path to delivering a cross platform application over the network. What we have now is actually pretty rad. We built it stone by stone, increment…

Literally, Java. If we spent all the effort we used up on making JavaScript work on Java instead, I’d be typing this from my Moon habitat. But we instead chose a pig, buried it under layers of lipstick, and strapped a jet engine onto it. Sure, it’s airworthy, but was it the best way to allocate resources?

I wouldn't say we chose a pig and buried it under layers of lipstick. I think it's more accurate to say people realized:

1) You could deliver software via a browser with some clever hacking

2) That delivering software via a browser had some extremely attractive properties compared to other approaches

Those clever hacks turned into real applications and those became real products. As people built applications on top of browsers, the browsers evolved to be a better environment for building applications. It was very organic.

The actual language we ended up using is just a byproduct IMO. I don't think people chose JavaScript, they chose the browser and the browser had JavaScript. And since the browser had JavaScript, we kept pushing the limits of JavaScript because we needed to deliver applications to the browser.

Honestly hard to see this happening efficiently in any other way. All things considered, the web platform is pretty fantastic compared to the software distribution story in every other ecosystem. I'd argue that we allocated resources pretty well on this one!

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

#276

Post by chrismorgan »

mardifoufs wrote: post #264
chrismorgan wrote: post #176

Earlier quoted context omitted.

I believe it’s still wildly wrong. Had arp242 not spoken up at that time, I’d have been saying something similar, because the numbers were to me blindingly obviously extremely unrealistic. The entire HTML Standard (which is somewhat of a misnomer now, it covers much more than just HTML, quite a bit of CSS interactions, other web platform functionality, JavaScript APIs, and the likes) is now about half a million words…

How do you even start implementimg such a spec? I know it's probably a dumb question but how would one structure their code to check all those boxes? Does it usually involve reading the entire spec, then figuring out the foundational parts and building from there? Does that work when you need multiple specs to "fit" together? How do you make sure or even check that some code you built for some part of the spec does n…

Other than layout and rendering, implementing HTML, ECMAScript and CSS is genuinely easy. There’s a lot of it so that it’ll take you a long time, but it’s very much not hard, because the HTML and ECMAScript specs fully spell out the algorithm, telling you exactly what you must do (or, more precisely, what you must be equivalent to doing: e.g. “implementations must act as if they used the following state machine to tokenize HTML”), so it’s largely mechanical. This is very unusual in specs. I wish it were less so.

Take a look through https://html.spec.whatwg.org/multipage/parsing.html. It’s verbose but very approachable, very implementable.

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

#277

Post by sundarurfriend »

tobr wrote: post #50
thrdbndndn wrote: post #30

Others have already mentioned performance is one of the hard part. Another aspect is that for any complex, large-scale project like browser, lots of, if not most of, effort is actually in the long tail: to make 90% or even 99% websites work probably is as hard as making the rest 1%. So while the team probably could cruise through when working on current gen spec and popular sites like Discord/Twitter, it's what left…

Is this something you know from experience or are you armchair guessing? If I recall correctly, the work Andreas did at Apple was mostly focused on performance, and Safari has long had a reputation for excellent performance. Maybe you’ve also done that type of work, but otherwise I’ll trust his judgement.

The replies to your comment seem to confirm that this is just armchair guessing.

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

#279

Post by Sakos »

pdpi wrote: post #84
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.

The point isn’t that “getting X to work” is a one-and-done job. Rather, you’re using major websites as indicators for what features to target next, because those are largely one-and-done.

Even if they do change, any other site now or in the future that uses the previous functionality will work because you already implemented it.

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

#280

Post by alex_lav »

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
Post reply on HN