3 ms·
I'm not going opine on the list of removed features, but if the author is interested in a browser that's easy to understand, written in a memory-safe language,
by pavpanchekha 5y ago
I'm not going opine on the list of removed features, but if the author is interested in a browser that's easy to understand, written in a memory-safe language, and (heh) eschews performance in favor of simplicity...
May I recommend the book I'm writing about how web browsers work? https://browser.engineering https://browser.engineering
It implements a (very simple) web browser in about 1000 lines of Python, and it's pretty easy to extend with new features (many of which are exercises in the book). I'm working on the seventh chapter right now---it adds tabs.
- axiosgunnar 5y agoHi, this looks interesting, but I personally preferred the style of https://hpbn.co/ https://hpbn.co/. There, instead of teaching me how to implement my own internet, it gave me a high level overview of networking history and design decisions. After reading that book I can now keep those constraints in the back of my head when developing web applications. I would love to read something like that for browsers: Instead of teaching me how to write a browser in Python (which is cool I guess for a weekend project if one is into that), it would show me a high level history and design decision overview and explain what was difficult and how it was solved, what hacks were necessary, what is still an unsolved problem, etc. My hope would be that from such a website I could take away key bits of information that I could leverage in daily coding, say „DOM nodes earlier in the document get rendered faster than later in the document because X“ or „display: none is much more costly than opacity 0 because X“ or „XSS attacks will never be able to be 100% solved because X“ or something like that. I hope my feedback is useful? Good luck anyways!
- pavpanchekha 5y agoThanks. 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.