So you want to build a browser engine

No. Tauri is not a web browser. It uses the existing platform browser.

This would be more like Servo which I believe is focusing on embedded use cases. It makes sense because for Electron/embedded you don't need it to work for every site (really really hard), you only need it to work for one site. (Or a few hundred/thousand if you count all your users.) That is several orders of magnitude easier.

I'm writing one for fun: 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 ;)

I think sooner or later you're going to want to load lower-trust content --- IFRAMEs of third-party Web content, or sandboxed extensions, or something like that. Building your entire architecture on the assumption you'll never have to do that is very risky.

I was inspired to write it by reading about Ladybird, so I wrote it for Andreas Kling basically :-). But there is also Flow: https://www.ekioh.com/flow-browser/ and Servo. Maybe in the future someone else will try. Also I think it's fun to think about these things even if you're not building a browser engine. It only took about 90 minutes to write.

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.