Hacker News new | past | comments | ask | show | jobs | submit
> 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.

Sure, if you're willing to write a renderer for something that looks like HTML but isn't then that's a lot more tractable. But at that point why not just do something better than HTML? Most of the effort is in the engine anyway.
loading story #41858794