https://news.ycombinator.com/item?id=28898157 (409 points | Oct 19, 2021 | 63 comments)
Web Browser Engineering: Scheduling tasks and threads - https://news.ycombinator.com/item?id=30336408 - Feb 2022 (3 comments)
Web Browser Engineering - https://news.ycombinator.com/item?id=28898157 - Oct 2021 (63 comments)
How Browsers Lay Out Web Pages - https://news.ycombinator.com/item?id=26707368 - April 2021 (50 comments)
Web Browser Engineering (A Book) - https://news.ycombinator.com/item?id=24055748 - Aug 2020 (1 comment)
Apparently some of it now runs in the browser ("in the book itself") by compiling Python to JS?
Browsers seem like mysterious, undecipherable black boxes, which is very likely how G wants them to be perceived, but that is cracking by seeing the efforts/results of such projects like ladybird and others!
I hope to one day be able to jump in and contribute to break that moat! And this books looks like an amazing start!
The moat isn't caused by a lack of non-chrome browser engines, it's because so few people use a non-chrome browser engine. Firefox already exists - it's just that ~no-one uses it and for websites that don't work with it those users have learnt to just open up chrome.
I'd love for the moat to be broken, and contributing to a browser engine like ladybird would be fun - but it doesn't contribute to breaking the moat. I'd love to know what would.
If anyone's looking for a reason to try a switch again, consider this your sign.
On chrome-based browsers the same pages on the same computers on the same network would load in within the blink of an eye, with no pause.
I eventually gave up and went back to chrome after Firefox being my daily for years. I prefer the dev tools in chrome anyway TBH
One of the authors of the book is Chris, who leads the Blink rendering team at G :)
But I do think there's a real lack of teaching material (why I wrote the book) and even "common vocabulary" to discuss browser internals, especially for the core phases like layout and raster, which is something Chris and I are hoping to create with the book.
(Hi Pavel, love the book!)
I'm definitely interested in going through this book.
> [1] The library is used as of 2023 in Google Chrome, ChromeOS, ChromiumOS, Mozilla Firefox, Mozilla Thunderbird, Android, Firefox OS, Flutter,[5] Avalonia (from Alpha 4), LibreOffice (from version 7.0) and RAD Studio[6](since version 12.0).
> [2] Changes to the Skia repository will be rolled into Chromium by the AutoRoll bot several times per day.
> [3] It serves as the graphics engine for Google Chrome and ChromeOS, Android, Flutter, and many other products.
[1]: https://en.wikipedia.org/wiki/Skia_Graphics_Engine
[2]: https://skia.org/docs/dev/chrome/
[3]: https://skia.org/
* layout
* event handling
which are not exactly trivial for a "real" application (whatever that means).
[0]: https://blogs.igalia.com/carlosgc/2024/02/19/webkit-switchin...
I'd like an alternative to HTML though. If I was to make a browser maybe I'd focus on replacing HTML because I can't stand it, and replacing js just because the runtime is heavy.
Like, a browser that only runs wasm and has nearly no JS runtime would make me giggle
That's not a browser.
More or less by definition, a browser is an application that can use HTTP (and potentially other protocols) to make requests to other systems and retrieve stuff described using HTML (and possibly other formats).
Sure, a tool that just loads wasm and executes it would be fun (and probably exists, at least for the local case). But it's not a web browser.
Yes there would be a DOM in addition
The interesting space is really post-HTML UI/document tech. There's another thread running about Typst which is a sort of better LaTeX. Markdown was highly impactful. There's a lot of scope for people to do interesting things in this space that are "HTML but better". It doesn't even have to be a markup format - Typst and React HTML both blur the lines between code and data. Jetpack Compose shows how to use Kotlin's DSL features to make something that looks a bit like a UI description but which is actually code.
Of course it means you have to then either distribute a 'browser' for your format, or find a way to display it in the browser. But compiling down to some JS/HTML/WASM thing is certainly possible. You can also use portable GUI toolkits like JavaFX; that also gives you accessibility. Or do both!
Once you define your own UI language there's a lot of scope to try things that HTML doesn't do well. An obvious one is separation of content and style. HTML tried and never really got there. XSL:T tried harder but was a weird pure functional language with XML as its syntax. React does quite well with going JSON->boxes but the underlying protocols are always ad-hoc and tacked on, so you can't really write useful tooling on top of that.
Another idea would be a format that's natively immune to XSS.
This keeps being repeated. But it leans on three false assumptions.
- That is has to be "finished" at all. For many use-cases, a subset (of a subset) might just be fine. The screen in my refrigerator, or the information display in a train, might want to render some HTML, but when the HTML is controlled and constrained, there's no need for "everything".
- That is has to adhere to "the spec". See above, but also if the HTML+CSS+JS is less controlled, quite a few use-cases it's fine to ignore lots of the quirks or even large parts of the specs. Even Chrome and FF don't implement "all", whatever "the spec" might be in the first place. But a browser in a TV set-top box, my e-reader, some dedicated wikipedia-device, or the "help section of an app" are fine if they break on complex sites.
- That is must be implemented from scratch. Even if you forego the big rendering engines, JS VMs and so forth, there's a lot of libs that do DOM handling, CSS parsing, JS runtime etc. There's a lot of shoulders to stand on, aside from "just run chrome headless".
By repeating this mantra that its not worth "building a new browser" or "rendering engine", we only cement the status quo further. And promote the idea that your car, refrigerator, test-runner, help-section, dashboard, e-reader and whatnot must run either a full chrome or firefox. We stiffle innovation.
sounds like a skill issue
Of course, jump forward 24 years and the KDE browser engine is basically the only game in town- the basis of both Chrome and Safari. Absolutely no way I saw that coming.
A web standard so simple, anyone can implement it!
One can dream...
(1) https://drewdevault.com/2020/03/18/Reckless-limitless-scope.... (2) https://100r.co/site/uxn.html (3) https://internet-janitor.itch.io/decker
EDIT: There is Project Gemini (https://geminiprotocol.net/), but it doesn't support styling or scripting.
There is also Gemini protocol.
I am just curious, what was the process that lead you to decide to use Python to implement the browser? I feel like JavaScript via node would have offered a more related programming experience.
Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head.
At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today.
As an aside, video decoding is offloaded onto hardware, so it's not as battery intensive as it used to be.
This is technically but not usefully true with most videos on the web today.
The video decode itself is accelerated, but each frame passes through JavaScript to be composited.
The only time video is fully hardware decoded is when it's a simple video element to a static video file.
What do you mean by that? There is no Javascript doing the actual compositing, and the actual compositing is (usually) hardware accelerated.
> The only time video is fully hardware decoded is when it's a simple video element to a static video file.
These seem in disagreement to me. The vast majority of videos on the web are simple video elements going to static video files. It is not usual for each frame to pass through JavaScript before being displayed.
I don't think that's true, and it's even less true once DRM video is involved - it becomes very difficult to get other software on the machine to even see the video, at least on Windows. You can very occasionally see bugs where the hardware accelerated playback ends up in a different place to where the browser thinks the video should have been put, too.
What does happen is the video data gets reassembled in Javascript (e.g. Video.js) because the native player doesn't support HLS. Not quite the same thing. It's just reformatting MPEG-TS to the similar but not identical MP4. Oddly, the browser in my LG TV does play HLS video natively, and I think Safari does?
1. The most "core" parts of layout, like CSS 2 stuff, is pretty poorly considered with a bunch of weird features that interact in strange ways. (Floats and clearance? Margin collapsing?) Some parts of this "core" were intended to be universal even though they're a bad fit for other layout modes. (Margin and padding, for example, don't have a clear purpose for say grid elements.)
2. It's not well-modularized the way JS APIs are. A JS API can often be implemented fairly stand-alone, but each layout module interacts with every other layout module since they can be nested in various ways. I think newer specs like grid are trying to be stricter with this but there are fundamental challenges: the actual 2D screen is a shared resource that different layout modes must split up.
Layout does not have to be so complex. There are dozens of GUI frameworks with simpler layout system. Those are enough for applications everyone uses.
The ones that use absolute pixel positioning fail when using different resolution displays.
The ones that use box packing fail when you need to deal with different sized displays.
The ones that use constraint programming fail when you need to layout hundreds or thousands of widgets.
CSS-style layout has its own pros and cons, but there is no alternative to it that is clearly better under all circumstances. If you doing layout and want to be resolution-independent, function on everything from phones to giant displays and have thousands of things to layout, CSS is actually likely better than any alternative.
But implementing a layout engine is doable. CSS is not magic; there's a spec that can be (meticulously) transformed into code. I've occasionally showed code like this to people frustrated that CSS seems arbitrary, just to show them that there is a logic to the execution environment. Granted, you're not going to regularly click into it the way you'd click into the implementation of a library, but it's no different from something like React in that regard. I think it helps!
I'm still working on CSS layout, with hopefully another paper coming soon.
Lol, no way.
People are always "guess what JS does, wut."
Doesn't hold a candle to Cascading Stylesheets.
I can't be the only one who wants a simpler layout language than CSS that's designed with two decades of hindsight to provide the maximum simplicity-expressiveness product. Are there any serious projects to engineer something like this, or has everyone given up and either embraced CSS3 (waiting for the LLVM backend) or gone back to plain text?
In the years since I’ve used a lot of tricks for web app CSS that I’m not sure I’m smart enough to figure out. But then I’ve never thought as long and as hard about typesetting as I did at the time so who knows.
Are web browsers, not considered to be "system software"
Browsers these days are about as complex as any operating system, or perhaps more complex when you consider all the non-systems stuff in them.
Basically, performance isn't a big focus, Python is very widely known and doesn't have too many quirks for non programmers to deal with, and systems languages emphasize error handling that, for expedience, we often need to skip.
I had an opportunity to run a tutorial on basic command line usage for newer software engineers. It's always fun to see people's expressions or read their reactions to seeing me telnet to port 25 and 80.
This comic book about how Chrome works is also a great place to get started: https://www.google.com/googlebooks/chrome/med_00.html