Comment by mike_hearn
21 hours ago
I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.
The interesting space is really post-HTML UI/document tech. There's another thread running about Typst which is a sort of better LaTeX. Markdown was highly impactful. There's a lot of scope for people to do interesting things in this space that are "HTML but better". It doesn't even have to be a markup format - Typst and React HTML both blur the lines between code and data. Jetpack Compose shows how to use Kotlin's DSL features to make something that looks a bit like a UI description but which is actually code.
Of course it means you have to then either distribute a 'browser' for your format, or find a way to display it in the browser. But compiling down to some JS/HTML/WASM thing is certainly possible. You can also use portable GUI toolkits like JavaFX; that also gives you accessibility. Or do both!
Once you define your own UI language there's a lot of scope to try things that HTML doesn't do well. An obvious one is separation of content and style. HTML tried and never really got there. XSL:T tried harder but was a weird pure functional language with XML as its syntax. React does quite well with going JSON->boxes but the underlying protocols are always ad-hoc and tacked on, so you can't really write useful tooling on top of that.
Another idea would be a format that's natively immune to XSS.
> I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.
This keeps being repeated. But it leans on three false assumptions.
- That is has to be "finished" at all. For many use-cases, a subset (of a subset) might just be fine. The screen in my refrigerator, or the information display in a train, might want to render some HTML, but when the HTML is controlled and constrained, there's no need for "everything".
- That is has to adhere to "the spec". See above, but also if the HTML+CSS+JS is less controlled, quite a few use-cases it's fine to ignore lots of the quirks or even large parts of the specs. Even Chrome and FF don't implement "all", whatever "the spec" might be in the first place. But a browser in a TV set-top box, my e-reader, some dedicated wikipedia-device, or the "help section of an app" are fine if they break on complex sites.
- That is must be implemented from scratch. Even if you forego the big rendering engines, JS VMs and so forth, there's a lot of libs that do DOM handling, CSS parsing, JS runtime etc. There's a lot of shoulders to stand on, aside from "just run chrome headless".
By repeating this mantra that its not worth "building a new browser" or "rendering engine", we only cement the status quo further. And promote the idea that your car, refrigerator, test-runner, help-section, dashboard, e-reader and whatnot must run either a full chrome or firefox. We stiffle innovation.
> I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.
Andreas Kling, the author of Ladybird browser, proves otherwise.
There is also QML as an alternative for HTML - see Canonic browser: https://www.canonic.com
Andreas hasn't finished. Also, I question to what extent it's worth it.
Another thing you can feasibly do is implement flexbox or a similar useful subset of layout! https://www.yogalayout.dev/ is one such library that powers React Native. Letting people bring CSS intuition when writing greenfield code for a simpler engine can be a great way to onboard users.
I was an early user of KDE back in 2000 and thought they were absolutely insane for trying to write their own web browser engine when it was controlled by Microsoft and Netscape. The web was just too complex and nothing worked in it, there was just no way a tiny open source project like that could make any useful headway with browser technology.
Of course, jump forward 24 years and the KDE browser engine is basically the only game in town- the basis of both Chrome and Safari. Absolutely no way I saw that coming.
> You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.
sounds like a skill issue