4 ms·

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 b

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.

dento 4y ago
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_Mode_and_Standards_Mode https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...
- Dalewyn 4y ago
  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.
  - Timwi 4y ago
    > 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>`.)
    - deleted 4y ago
      [deleted]
CJefferson 4y ago
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?
- kitsunesoba 4y ago
  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.
  - CJefferson 4y ago
    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/performance/ 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.
    - nicoburns 4y ago
      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.
      - deleted 4y ago
        [deleted]

dento 4y ago

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_Mode_and_Standards_Mode https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...

Dalewyn 4y ago
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.
- Timwi 4y ago
  > 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>`.)
  - deleted 4y ago
    [deleted]

CJefferson 4y ago

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?

kitsunesoba 4y ago
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.
- CJefferson 4y ago
  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/performance/ 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.
  - nicoburns 4y ago
    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.
    - deleted 4y ago
      [deleted]