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

231–240 of 349 posts

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

#231

Post by snakeboy »

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

> probably by 2–3 orders of magnitude So the web is maybe only 1.2 specs with 114,000 words? I think it's considerably more than that. If that estimate is off, it's by no more than a factor of 10, IMO. No need to exaggerate.

In the source comment he gives it's more explicit, but the "2-3 orders of magnitude" is referring to "the total", i.e. the 114 million words, not the number of specs.

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

#232

Post by riffraff »

yodsanklai wrote: post #225
cubefox wrote: post #224

This post doesn't give reasons to doubt that building a new state of the art browser is basically impossible now. It might well be possible to build a new browser that kind of works on many popular websites, and that would be surprising enough. But the amount of work needed to build something comparative to the rendering engines of Chrome, Firefox, or Safari, something really usable, would probably take decades rathe…

Is all the complexity of a browser in the rendering engine? can a browser be split into several components so that they can be rewritten concurrently?

Mozilla's servo seemed to be done in this fashion, so that some components were later brought to gecko/Firefox, so presumably you can do it.

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

#233

Post by kitsunesoba »

yodsanklai wrote: post #225
cubefox wrote: post #224

This post doesn't give reasons to doubt that building a new state of the art browser is basically impossible now. It might well be possible to build a new browser that kind of works on many popular websites, and that would be surprising enough. But the amount of work needed to build something comparative to the rendering engines of Chrome, Firefox, or Safari, something really usable, would probably take decades rathe…

Is all the complexity of a browser in the rendering engine? can a browser be split into several components so that they can be rewritten concurrently?

The vast majority of the complexity is in the engine. One can whip up reasonable chrome (browser UI) in whatever UI framework one prefers in a few days tops. While there are slightly more involved parts like writing the bookmarks and history systems, those are pretty run of the mill tasks that can be completed in a relatively short period of time.

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

#234

Post by illiarian »

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

To underscore something that might get lost in the wall: The entire premise given in Reckless, Infinite Scope is that the number of words in the specification is positively correlated with the intractability of implementing a given thing. From this foregone conclusion, it tries to quantify how much worse the task of implementing a Web browser is. The problem is that that the premise is a bad one; even if it takes mor…

And yet, it's a decent proxy. That, and the number of specs required (many of whom are locked behind IEEE, IEC etc. paywalls)

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

#235

Post by kitsunesoba »

ChickeNES wrote: post #105
ryanjshaw wrote: post #15

What we all REALLY care about: they went with C++ and Qt https://github.com/SerenityOS/serenity/tree/master/Ladybird

I would really like to see a version with a C API capable of being embedded, there's a lot of places where a lightweight HTML renderer would be useful, plus it would make it easier to port to other hobby kernels.

Agree. This market is currently cornered by WebKit, which is easily the most language and UI framework agnostic engine there is. Blink might be similarly easy to embed but I’ve not seen it used that way — Blink embedding tends to be via Electron, CEF, or Qt, whereas you might run into WebKit in some random program written with any number of UI frameworks.

There used to be Gecko as an option here too, but Mozilla decided that it shouldn’t be usable outside of XULRunner and made it effectively unembeddable unless you’re willing to commit to XUL.

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

#236

Post by smolder »

nashashmi wrote: post #187
ryanjshaw wrote: post #15

What we all REALLY care about: they went with C++ and Qt https://github.com/SerenityOS/serenity/tree/master/Ladybird

This was a missed opportunity to build in rust. Servo was the previous engine that got abandoned midway. They should have continued that.

This browser isn't that ambitious. They're not trying to revolutionize anything, just to make a working one.

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

#237

Post by illiarian »

arp242 wrote: post #205
illiarian wrote: post #194

Earlier quoted context omitted.

> and I suspect it’s bigger than everything else put together, apart from ECMAScript The thing is, it's not just the HTML standard. It's also all the standards it references. And all the standards they reference, and all the standards those standards reference, ad infinitum. For example, HTML 5 references SVG 2 which references CSS 2 which references Unicode and XML 11 . Or, to go the same route, HTML 5 references SV…

Essentially any specification that includes any kind of image support will include this kind of chain of specifications; just as any system that does networking will eventually end up with TCP, any system that does text ends up with Unicode, etc. Even the simplest possible 1995-esque browser will have to deal with that (support for images was added in 1993, and text and networking were always central).

> Even the simplest possible 1995-esque browser will have to deal with that (support for images was added in 1993, and text and networking were always central).

Indeed they did. Here's what author of KHTML said, https://twitter.com/LarsKnoll/status/1421121639845187585

--- start quote ---

Implementing a browser engine from scratch was a lot of work in 1999/2000, it’s close to impossible today.

--- end quote ---

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

#238

Post by Waterluvian »

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…

I really like this approach because it’s a low-effort way to prioritize development.

I did this with the CPU for my GameBoy emulator: I picked a game I wanted to work and just kept implementing opcodes each time it crashed with an “opcode not implemented” error.

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

#239

Post by illiarian »

rob74 wrote: post #67
hayleox wrote: post #33

Earlier quoted context omitted.

More specifically, Chrome used Safari's rendering engine, and Safari used Konqueror's rendering engine, because even in 2001, starting a browser engine from scratch seemed like too much work.

I would say that in 2001, starting a browser engine from scratch was more work than today, because (as other commenters have noted) since then the specifications have become more robust and the "tag soup" sites not following the specs have become fewer.

In 2001 the entirety of HTML+CSS spec was probably less than just some of CSS modules like CSS Color.

Today the complexity lies not in the robustness of the specs, but in the sheer number of of them, and their many interactions. I mean, just distance units... There are over forty of them

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

#240

Post by doodlesdev »

nicoburns wrote: post #89

The specs really are drastically better than they used to be. Compare the modern specification for CSS Table Layout ( https://www.w3.org/TR/css-tables-3/ ) with the older CSS2 one ( https://www.w3.org/TR/CSS2/tables.html ). The older one doesn't even attempt to define the "automatic layout algorithm" at all!

What is this supposed to mean in the website?

   > Not Ready For Implementation

   > This spec is not yet ready for implementation. It exists in this repository to record the ideas and promote discussion.

   > Before attempting to implement this spec, please contact the CSSWG at www-style@w3.org.
Post reply on HN