I hope the AI gets good enough to dynamically translate from one language to another with high reliability, in case not everyone is a fan of Python
Web Browser Engineering (2021)
41–50 of 138 posts
Re: Web Browser Engineering (2021)
#42It's refreshing that browser engineering seems to become a "trend" now. The ecosystem is quite sparse with basically only Google, Apple and Mozilla defining it. I'd like to see forward into a future with more independent browser engines.
Or perhaps an entirely new platform/protocol, since this one is completely saturated with complexity at this point.
Re: Web Browser Engineering (2021)
#43Earlier quoted context omitted.
Yes [4]. > [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 an…
Whoa. Somehow I have not heard of this. Can this be used to make cross-platform GUI apps?
Sure you can, it's a 2D graphics library. It's more like the JS Canvas API though instead of a UI framework.
Re: Web Browser Engineering (2021)
#44One great thing about this book is the 'stuff I didn't do' part. 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…
> 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.
I think by "JavaScript" here you mean rendering—that's partially true. In macOS and Windows these days (also I think Linux with GTK4 on Wayland, though only in a limited way), the window manager is itself composited and a window can send a small display list to that window manager for it to composite. In that case, it's possible to actually have the video decoding to happen entirely in hardware and never have the browser directly interact with decoded video bits. That said usually the window manager compositor is pretty limited and the browser will only do this when the stars align. The sort of things that can break it are any kind of weird clipping, transparency, or effects applied to the videos.
Re: Web Browser Engineering (2021)
#45One great thing about this book is the 'stuff I didn't do' part. 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…
This Babylonian tower will crumble one day.
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.
Re: Web Browser Engineering (2021)
#46One great thing about this book is the 'stuff I didn't do' part. 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…
For the absolutely massive amount of code one needs to implement for production-grade CSS layout, the Servo source code is illustrative and IMO quite cool to see. For instance, this file just implements block and inline contexts; there's a bit of Rust boilerplate here, but the vast majority of lines are "business logic" around various parts of the specification. And there's a whole folder of these. https://github.com/servo/servo/blob/main/components/layout/f...
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!
Re: Web Browser Engineering (2021)
#47why python, why not a system programming language like C, OCaml or Go (or newer languages like zig or odin) Are web browsers, not considered to be "system software"
Going to take a wild guess that maybe they're going to rely on the excellent, extensive standard library of Python which C and Zig can't compete with. The second constraint was probably that they want to keep the number of lines of code low to encourage more people to buy the book. That's where Python does better than Go - you can do a lot with list comprehensions and you don't have if err != nil every few lines.
Re: Web Browser Engineering (2021)
#48One great thing about this book is the 'stuff I didn't do' part. 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…
> 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.
> each frame passes through JavaScript to be composited
What do you mean by that? There is no Javascript doing the actual compositing, and the actual compositing is (usually) hardware accelerated.
Re: Web Browser Engineering (2021)
#49why python, why not a system programming language like C, OCaml or Go (or newer languages like zig or odin) Are web browsers, not considered to be "system software"
I think the point is to demonstrate how things work and are designed, and python is easy for everyone to understand. I don't think the author is recommending trying to write a production web browser in python. (or probably at all ;)
Re: Web Browser Engineering (2021)
#50One great thing about this book is the 'stuff I didn't do' part. 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…
> 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.
> not usefully true with most videos on the web today
> 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.