Hacker News Reader

Comment by kitsunesoba | Hacker News Reader

It's an unpopular opinion perhaps, but I think infinite backwards compatibility for web HTML/CSS/JS will need to be broken eventually… at some point the cruft becomes too much to wade through and number of optimizations that are unrealizable as a result too great to ignore. If nothing else there will probably need to be a mode that pages can opt into that breaks anything older than a certain cutoff point in exchange for a performance boost.

View on HN

This is already occurred, in some limited from. See quicks mode [1], for instance. Also there is WebAssembly, which should be the replacement for JS. At some point a good-enough UI toolkit for it will be written, and then that could replace HTML/CSS.

https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...

For the younger greenhorns among us: Once upon a time, we used to declare what version of HTML a page was written in with the doctype tag at the very top of the file.

Certain versions of HTML thus declared, incorrectly formed doctypes, or more often the absence of the doctype declaration altogether, would tell most rendering engines to enter Quirks Mode and render the page with backwards compatibility as the highest priority.

> we used to declare what version of HTML a page was written in with the doctype tag at the very top of the file.

Um, we still do that. It's just that the doctype for HTML 5 is very short and doesn't mention the version number explicitly. (It's `<!DOCTYPE html>`.)

I haven’t seen an browser devs suggest there are large performance boosts that could be unlocked by throwing away backwards compatibility. Can you point me to any?

I can’t point to any examples, but it’s hard to imagine that a page being able to tell the browser for example, “hey, the only layout methods used in this page are flexbox and grid” wouldn’t enable code paths with far less guesswork, caveats, etc — the ruleset in that situation is so much more simple.

Browsers already do quite a bit of this -- for example one easy way to hurt performance is to have events that trigger on scrolling ( https://developer.chrome.com/docs/devtools/rendering/perform... ). However, the current way to fix this is "don't do that". I'm not sure it would be faster for a page to announce it won't do things in advance, than the page just not do them, and then the existing fast paths get used.

It might be nice to have a mode where you opt into having the slow-path code ignored (/it's behaviour modified) in case you use it accidentally.

Reply on news.ycombinator.com