Thanks. I agree a sort of "design decisions behind web browsers" would be an interesting book, and some of the later chapters we're writing now (11 and onward)

Thanks. I agree a sort of "design decisions behind web browsers" would be an interesting book, and some of the later chapters we're writing now (11 and onward) have more of that flavor. But there's a lot of background knowledge necessary to even fill in those "X"s. You know, all the major browsers are, like, tens of millions of lines of code, bigger than (say) the Linux kernel. And unlike the kernel, there's no good overview out there on the basic architecture and the basic concepts, stuff like the layer tree or the task queue or hit testing. It's hard to discuss, say, why one DOM API is slower than another without having those concepts in mind. So, like, DOM nodes earlier get rendered faster (if the network is real slow and if ...) because they arrive over the network earlier. "display: none" is a lot cheaper because it doesn't produce a layout object, while opacity 0 probably goes all the way to the layer tree. XSS attacks are hard because JS can be embedded into HTML without being demarcated or separated from it. But these explanations presume some understanding of browser networking and the layout tree and the JS environment. For some simple things the "folk understanding" of these things suffices, but the joy of the toy web browser isn't that it's a fun weekend project, it's that each of those concepts is something you can pull up on the screen, read, and then understand as a concrete piece of code.