3 ms·

I'm writing one for fun: https://sr.ht/~bptato/chawan/ https://sr.ht/~bptato/chawan/ "Fixed-width text to a grid" makes things easier (sometimes), but I think

I'm writing one for fun: https://sr.ht/~bptato/chawan/ https://sr.ht/~bptato/chawan/ "Fixed-width text to a grid" makes things easier (sometimes), but I think it still qualifies. On the article itself; it might be better to start with more... basic things than the optimizations it talks about: * Cascading & layout must be cached and optimized - far from trivial. Layout is one of the hardest parts to get right at all, to make it fast as well is another level... and I'm just talking caching, not even multi-threading. * The "web platform" contains a very large amount of poorly thought out features harmful for user privacy and/or security. You can choose between convenience (opt out) and privacy (opt in), or try to balance the two as major browsers do. Both is often impossible. * "Serialize the entire application state" sounds like the most complex thing you can come up with as a distinguishing feature. Much more low hanging fruit exists if you give up on writing a Chromium clone. e.g. a fun side project I've had is making my browser "protocol-agnostic", or adding a bunch small QOL stuff for myself. You can probably find new ideas easily once you start out. * Older browsers are useful for inspiration too. The coolest features in mine are often just carbon copies of the same things from w3m, just a bit more polished. Reading about what historical engines did - even IE! - is often enlightening too. Sometimes it's just a smaller scale of what engines do now, and easier to implement. Other times it's a whole different approach. * It's easy to get lost in the details - careful with perfectionism. As you start getting more components interacting, it will slowly become clear when the naive approach is wrong and how to improve it. Overall, it takes time, but is also fun and rewarding - you will learn a lot, even without replacing Chromium.[0] That said, if you want to learn how "modern" browsers work, getting involved with a "modern" engine itself is probably much more productive. [0]: To write a Chromium replacement, you may have to reincarnate as awesomekling ;)

roca 2y ago
I guess one of my points is that layout algorithms are not really part of the "most basic" decisions anymore. Replacing layout algorithms is actually a lot less disruptive to the engine architecture than switching to site isolation, say.
- shiomiru 2y ago
  Fair; re-reading TFA, now I realize you explicitly instructed me to stop reading in the first paragraph :) Trying to redeem myself with an on-topic question: isn't what you want more of a "refactoring of Blink" than "building a browser engine"? I would be surprised if a complete rewrite was really necessary for the features you want, since "saving state" already happens to some extent in all engines (even if it's just reloading from the cache) and I've seen reports about Gecko integrating multi-core cascade from Servo. What makes it hard to incrementally improve upon the current engines?
  - roca 2y ago
    Indeed you can incrementally improve existing engines, and certainly that's what you would try to do if you wanted one of those specific features. But I didn't write the post because I want those features, I wrote it in the hope that it might be helpful to people who are already planning to write a competitive browser engine from scratch. Yes, for almost every conceivable features you'd be much better off adding it to an existing engine. Maybe you won't get buy-in from the core maintainers, so you'll have to maintain an out-of-tree branch, but that's still going to be much less work than doing your own engine.
jwells89 2y ago
> Much more low hanging fruit exists if you give up on writing a Chromium clone. One idea that’s crossed my mind (may never get around to trying it) is writing an engine that completely ignores everything that’s not modern HTML5 and CSS3. That’s still a lot but it seems like it’d cut down on the scope significantly. This engine wouldn’t be very useful as a browser but it’d probably be enough for displaying bespoke web content in an app or something like that.
- pavpanchekha 2y ago
  It's not really clear what this even means. HTML5 and CSS3 aren't new versions of HTML and CSS that obsolete the prior stuff; they are extensions to what already existed. So, for example, as far as I know, every web browser uses the HTML5 parsing algorithm for parsing HTML. This algorithm is very complicated, because it describes what parse tree to produce for any possible document. There's not, like, a separate HTML4 parsing algorithm; the HTML5 parsing algorithm replicates a lot of the complexities of pre-HTML5 parsing, but standardized. Similarly, in CSS 2 the biggest complexities are things like floats, inline layout, margin collapsing, and stacking contexts. (My PhD was most of a standards-compliant CSS 2.1 layout engine.) There's not a CSS inline layout algorithm (the thing that puts words into lines) other than the CSS 2 one, though CSS 3 does add a lot more features. In other words: the browser doesn't have a separate code path to handle old content. Instead, CSS 3 contains layout algorithms that extend CSS 2 but they don't replace them.[1] Similarly HTML 5. There are obsolete features you could probably dump (obsolete image formats, obsolete codecs) or rarely-used features (eval, document.write) or edge cases that probably don't matter that much (margin collapsing) or features where maybe your user base doesn't need it (writing direction? floats?) but this is really not so different from what the article talks about: a WebView/Electron replacement, where you commit to supporting a known universe of pages instead of the whole web. [1] Granted some features like floats have become a lot less necessary, since a lot of their use cases can now be replaced by flex-box.
  - cxr 2y ago
    It's a semi-noob illusion that focusing only on modern standards and practices would surely result in a leaner implementation. This goes all the way back to the big push for web standards in 1998—e.g. you can find Slashdot Q&As from the early 2000s where people bring up the idea of how much smaller the browser could be without quirks mode and IE compatibility and then get corrected about how much of the code base this stuff actually takes up.

roca 2y ago

I guess one of my points is that layout algorithms are not really part of the "most basic" decisions anymore. Replacing layout algorithms is actually a lot less disruptive to the engine architecture than switching to site isolation, say.

shiomiru 2y ago
Fair; re-reading TFA, now I realize you explicitly instructed me to stop reading in the first paragraph :) Trying to redeem myself with an on-topic question: isn't what you want more of a "refactoring of Blink" than "building a browser engine"? I would be surprised if a complete rewrite was really necessary for the features you want, since "saving state" already happens to some extent in all engines (even if it's just reloading from the cache) and I've seen reports about Gecko integrating multi-core cascade from Servo. What makes it hard to incrementally improve upon the current engines?
- roca 2y ago
  Indeed you can incrementally improve existing engines, and certainly that's what you would try to do if you wanted one of those specific features. But I didn't write the post because I want those features, I wrote it in the hope that it might be helpful to people who are already planning to write a competitive browser engine from scratch. Yes, for almost every conceivable features you'd be much better off adding it to an existing engine. Maybe you won't get buy-in from the core maintainers, so you'll have to maintain an out-of-tree branch, but that's still going to be much less work than doing your own engine.

jwells89 2y ago

> Much more low hanging fruit exists if you give up on writing a Chromium clone. One idea that’s crossed my mind (may never get around to trying it) is writing an engine that completely ignores everything that’s not modern HTML5 and CSS3. That’s still a lot but it seems like it’d cut down on the scope significantly. This engine wouldn’t be very useful as a browser but it’d probably be enough for displaying bespoke web content in an app or something like that.

pavpanchekha 2y ago
It's not really clear what this even means. HTML5 and CSS3 aren't new versions of HTML and CSS that obsolete the prior stuff; they are extensions to what already existed. So, for example, as far as I know, every web browser uses the HTML5 parsing algorithm for parsing HTML. This algorithm is very complicated, because it describes what parse tree to produce for any possible document. There's not, like, a separate HTML4 parsing algorithm; the HTML5 parsing algorithm replicates a lot of the complexities of pre-HTML5 parsing, but standardized. Similarly, in CSS 2 the biggest complexities are things like floats, inline layout, margin collapsing, and stacking contexts. (My PhD was most of a standards-compliant CSS 2.1 layout engine.) There's not a CSS inline layout algorithm (the thing that puts words into lines) other than the CSS 2 one, though CSS 3 does add a lot more features. In other words: the browser doesn't have a separate code path to handle old content. Instead, CSS 3 contains layout algorithms that extend CSS 2 but they don't replace them.[1] Similarly HTML 5. There are obsolete features you could probably dump (obsolete image formats, obsolete codecs) or rarely-used features (eval, document.write) or edge cases that probably don't matter that much (margin collapsing) or features where maybe your user base doesn't need it (writing direction? floats?) but this is really not so different from what the article talks about: a WebView/Electron replacement, where you commit to supporting a known universe of pages instead of the whole web. [1] Granted some features like floats have become a lot less necessary, since a lot of their use cases can now be replaced by flex-box.
- cxr 2y ago
  It's a semi-noob illusion that focusing only on modern standards and practices would surely result in a leaner implementation. This goes all the way back to the big push for web standards in 1998—e.g. you can find Slashdot Q&As from the early 2000s where people bring up the idea of how much smaller the browser could be without quirks mode and IE compatibility and then get corrected about how much of the code base this stuff actually takes up.