Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Browser Engineering (2021)

browser.engineering

Post reply on HN
Print view View original

61–70 of 138 posts

Re: Web Browser Engineering (2021)

#61

Post by DanielHB »

mannyv wrote: post #32

One 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 React Native the facebook engineers just gave up and were like "all you get is flexbox layout" and people were quite okay with that (although some people grumble about lack of display grid)

https://github.com/facebook/yoga

Re: Web Browser Engineering (2021)

#62

Post by fouric »

mannyv wrote: post #32

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

Layout is so difficult that it made me quit using Common Lisp and ncurses to build my passion project and become the very thing I swore to destroy (a React developer).

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?

Re: Web Browser Engineering (2021)

#63

Post by tannhaeuser »

btown wrote: post #46
mannyv wrote: post #32

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

FWIW, Pavel, one of the authors, has devoted considerable time into what is one of the very, very few attempts at a formal specification for CSS (the static/float layout fragment cf [1]). It's a Racket program generating Z3 SMT solver code for verifying an instance layout (which also looks like Scheme) so it's not for the faint-hearted ;) but maybe just what an FP fan on HN is looking for as a challenge.

[1]: https://pavpanchekha.com/blog/css-floats.html

Re: Web Browser Engineering (2021)

#64

Post by pavpanchekha »

tannhaeuser wrote: post #63
btown wrote: post #46

Earlier quoted context omitted.

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…

FWIW, Pavel, one of the authors, has devoted considerable time into what is one of the very, very few attempts at a formal specification for CSS (the static/float layout fragment cf [1]). It's a Racket program generating Z3 SMT solver code for verifying an instance layout (which also looks like Scheme) so it's not for the faint-hearted ;) but maybe just what an FP fan on HN is looking for as a challenge. [1]: https:/…

Wow, thanks, you always suspect no one has actually read the papers :) That was a crazy project... I eventually got it passing almost all of the WPT css2 fragment.

I'm still working on CSS layout, with hopefully another paper coming soon.

Re: Web Browser Engineering (2021)

#65

Post by pavpanchekha »

systems wrote: post #40

why 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"

Author here, I wrote about this on the blog: https://browserbook.substack.com/p/why-python

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.

Re: Web Browser Engineering (2021)

#66

Post by pavpanchekha »

nindalf wrote: post #47
systems wrote: post #40

why 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.

Definitely the second reason, but we actually try hard not to use too much of the standard library, for easy porting. But it's nice that sockets & ssl are standard, plus a (bad) GUI library.

Re: Web Browser Engineering (2021)

#67

Post by PaulDavisThe1st »

vbezhenar wrote: post #45
mannyv wrote: post #32

One 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.

Actually, almost every GUI toolkit's scheme for layout has issues, and none of them are perfect.

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.

Re: Web Browser Engineering (2021)

#68

Post by PaulDavisThe1st »

Rohansi wrote: post #43
pmarreck wrote: post #37

Earlier quoted context omitted.

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.

Which rather importantly means that you still need to find something else to do:

* layout

* event handling

which are not exactly trivial for a "real" application (whatever that means).

Re: Web Browser Engineering (2021)

#69

Post by PaulDavisThe1st »

01HNNWZ0MV43FF wrote: post #31
currygen wrote: post #24

It'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.

Something that uses less RAM would be nice. Other than that and the spyware from Capital-G Google Chrome and Capital-M Mozilla Firefox, I don't have a problem with it being sparse. It's millions of hours of de-duplicated work. 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 browse…

> Like, a browser that only runs wasm

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.

Re: Web Browser Engineering (2021)

#70

Post by pavpanchekha »

wslh wrote: post #54

Is there a promotional code for HN? I was a happy user of HTMLUnit [1] with Jython [2] in the past and am very interested in a future where we can automatically generate portions of browser code using code generation and verification techniques. I've never felt as comfortable with tools like Playwright/Cypress/Selenium as I did with HTMLUnit (with all due respect to both). [1] https://htmlunit.sourceforge.io/ [2] htt…

The book isn’t out yet, so no promo code, but the whole thing is free online.
Post reply on HN