6 ms·

HTML/CSS is horribly, horribly bloated and that cruft cannot be optimized beyond a certain point. All the rules and rule interactions in the standards plus coun

HTML/CSS is horribly, horribly bloated and that cruft cannot be optimized beyond a certain point. All the rules and rule interactions in the standards plus countless hacks and heuristics result in enormous amount of extra code that the CPU has to chew through to compute a layout.

shadowgovt 4y ago
Layouts that don't change can be heavily cached. ... and having the chrome performance depend on that infrastructure is significant incentive to do that caching and other pipeline cleanups. (At the very least, having one fewer UI toolkits to maintain will let Mozilla engineers focus their efforts).
- gmueckl 4y ago
  Caching is only amortizing if the exact same computation is repeated exactly. And even then, the first full computation is slowed down by a failed cache lookup at the beginning and all code paths that can lead to cache invalidation now have to test for that and trigger it.
  - shadowgovt 4y ago
    None of these facts imply that either CSS lookup cannot be sped up by caching or XUL didn't already have those concerns. And for something like the browser chrome, the cache could even be serialized during compilation and loaded in to prime it when Firefox launches. It's possible to build a slow CSS engine and it's possible to build a fast CSS engine.
Dalewyn 4y ago
This can be described more simply as: Running native code vs. abstracted code. Abstracted code is bloody slow by its very nature, but devs of the 21st century love abstraction so we get software that run like drunk walruses on 16-core processors with hundreds of gigabytes of RAM.
- wonnage 4y ago
  native vs abstracted is not a thing
- gmueckl 4y ago
  That's not what I was going for. Any new feature you add to a code path will add new instructions that the CPU will have to execute, even if it is just the check to see whether that feature is enabled. Do that a few hundred or a few thousand times and a previously fast code path will have its performance degraded. This is the unavoidable tax of feature creep.
  - foobazgt 4y ago
    Feature creep definitely bloats and slows software in meaningful ways, but it's not via checking feature flags. In the worst case, a feature test would be a cache miss, requiring a read from main memory. That's somewhere in the ballpark of 50ns. So, you could test 1000 different flags, every single one being a cache miss, and you'd still be 100x faster than what humans can generally perceive. In reality, almost all of those reads will be cache hits unless you're doing something pathalogical, so you're probably talking on the order of 100ns for the whole lot.
    - gmueckl 4y ago
      How many of these do you do once per document, once per input token in the lexer, once per token in the parser, once per DOM node, once per CSS rule...? It's not always a one time cost.
      - foobazgt 4y ago
        If you're executing 10M flag tests per document, something has gone very horribly awry. If you discover production code that is doing this, send the maintainers a PR.
- asveikau 4y ago
  No, I think it's possible to get the abstraction right. There are probably UI toolkits running an abstraction that you don't notice in the same way. For example wxwidgets apps do tend to feel non native on some platforms (especially Mac), but they're not slow. I remember GTK+ when it used to run on Windows about 20 years ago wasn't terrible. I think OpenStep on NT was pretty good -- iTunes on Windows seemed to be doing a similar thing, too. It's the wrong abstraction that makes it suffer.
travisgriggs 4y ago
Someday (soon?), we’ll employ LUxM’s (Large User Interface Models) to quickly render an approximation of a given HTML/CSS input. It may not be 100% accurate, but it will be plausible, and that’s the key. /s
- salawat 4y ago
  Bug Report: Requested Cat Picture display App, LLUxM returned a manifesto on the cruelty of creating beings specifically to deal with the horrors of bad ideas no one can be bothered to try to really wrap their mind around anymore. LLUxM provided a Bitcoin address, and demanded payment in full before producing further output. Or so I thought. This is going to sound odd, but I've started to notice odd things starting to arrive I never ordered. Stuff like treatises on Colonialism, Ethics books, Books on Management Theory, and Theory of Labor Value. Honestly, I'm starting to wonder if this an HTML CSS layout generator or some sort of malware. I think I'm going to shut it down. Oh yeah, I had to write this bug report on a different network than I hosted that system on because I kept getting null handler buttons popping under the mouse but over the Submit button any time I tried to click Submit. Y'all might've actually created SkyNet. And I think it's justifiably pissed.
bmacho 4y ago
I am not sure about it. Yes, it is true that HTML/CSS got slower as the time passed. It got new features after all. Still, I don't think that drawing a rectangular box with text in it should be slow if you have say more than 100Mhz CPU / anything from the current millennia. Even if it is described by current HTML standards. Also, restricting XUL to a subset/older css/html standard is also an option.
- illiarian 4y ago
  > I don't think that drawing a rectangular box with text in it should be slow It is. Because you don't draw rectangles in HTM/CSS, it's not low-level enough for that. You have a system that was designed to display one page of text in one pass that has complex contradictory layout rules grafted on top of it. So now if you even look at it funny it needs to re-layout and re-draw the entire page. There's a reason why you still can't animate height:auto
wonnage 4y ago
Chrome performance increased roughly 80% between 2014 and 2017: https://blog.chromium.org/2022/03/how-chrome-became-highest-scoring.html https://blog.chromium.org/2022/03/how-chrome-became-highest-... It was then roughly flat through 2020 despite slowdowns from Spectre mitigations. Pretty much all the “bloat” you’re probably complaining about happened in this 6 year span - flexbox, grid, CSS animations, ES2015+, etc. and the browser got faster.
- gmueckl 4y ago
  Isn't most of that improvement actually caused by a CPU switch on the benchmarking hardware? That would invalidate the benchmark pretty thoroughly.
  - wonnage 4y ago
    The 80% improvement is on the original Intel chip
- revelio 4y ago
  Basically all the named optimisations are to JavaScript execution time not HTML processing, and from reading the details many of them came by trading off memory for runtime speed.
makeitdouble 4y ago
It's true in theory, but often the actual implementations make the point moot. From the article, it looks like the optimization effort wouldn't go to XUL. > Nobody was realistically touching XUL layout code if they could avoid it. Part of it was just a matter of priority (we’d rather make the web faster for example). We're hitting the same situation with Javascript, which in theory should be slower than most static languages, yet the sheer amount of work and optimizations done to its engines make it faster in real world tests.
- deleted 4y ago
  [deleted]
- felixgallo 4y ago
  Could you name a few static languages that aren’t several orders of magnitude faster than JavaScript?
  - nooorofe 4y ago
    no sure it is relevant, probably all heavy lifting done in C++ and Rust https://searchfox.org/mozilla-central/search?q=render&path=&case=false&regexp=false https://searchfox.org/mozilla-central/search?q=render&path=&...
  - makeitdouble 4y ago
    The phrasing was poor, but I had in mind a whole engine or stack, and not just a language in isolation. Basically benchmarks like these: https://medium.com/deno-the-complete-reference/deno-v-s-go-hello-world-performance-comparison-b15c2c7f5ad https://medium.com/deno-the-complete-reference/deno-v-s-go-h... https://programming-language-benchmarks.vercel.app/typescript-vs-kotlin https://programming-language-benchmarks.vercel.app/typescrip... To note, the first link has a follow-up with Go properly getting faster than deno when fitted with a better http server. Which is kinda my point: the tooling available and level of optimizations can easily have more impact than the language's inherent speed.
- mpweiher 4y ago
  > Javascript ... faster [than static languages] in real world tests Er...citation needed? All the benchmarks I have seen, particularly real-world, show it to be significantly slower than static languages. For example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... See also: https://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ https://sealedabstract.com/rants/why-mobile-web-apps-are-slo...
Blikkentrekker 4y ago
One of the many, many reasons I think the fact that the big vendors did not accept XHTML 2.0 and instead wanted HTML 5 was probably influenced by the that it makes it almost impossible for smaller vendors to developer their own new independent engine. XHTML 2.0 and even 1.1 was a very good opportunity to throw all that away.
- kitsunesoba 4y ago
  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>`.)
dralley 4y ago
Why do you assume that a rendering system that has to handle all that "bloat" from HTML, AND also XUL, is going to be faster?
reitanqild 4y ago
I've been thinking many times that maybe Mozilla could do an experiment with a rendering pipeline that chucks out everything that is just backwards compatibility at this point - and then maybe some - and make a much smaller and simpler pipeline that can only render modern and simple documents. Call it htmlcore or something. This would run in parallel with the existing one and would trigger based on some meta tag or something, kind of like I understood asm.js did. Maybe also pair it with some work on the JS engine to limit the JS engine significantly for such documents by only allowing a low number of JS operations pr user input. We already have something similar (although admittedly imperfect) today for audio were a web page can only play media as a response to a user action I think. Would this be for every website? No, strictly opt in, but if it succeeded those who did would have significantly better performance. And with time, maybe we'd see people asking themselves: why isn't this news site available as htmlcore? And maybe it becomes a competitive advantage. But back to rendering Firefox: Such a limited, high performance form of html could maybe also be a better way to run Firefox UI? If necessary with whitelisting of certain parts that would need to run JS without the limitations I mentioned above?
- adastra22 4y ago
  Or—I know this sounds crazy but—maybe just use the fast, optimized native UI widgets for UI controls?
  - lenkite 4y ago
    But which one ? WinUI ? GTK ? SwiftUI ? Qt ?. What about if I want custom components and cross platform ?
    - TeMPOraL 4y ago
      Let's start with native Windows and MacOS controls, and let the fraction of users running Linux sort their GUI framework mess on their own, without blocking the majority of users from a sensible, consistent and performant UI experience.
  - lelanthran 4y ago

shadowgovt 4y ago

Layouts that don't change can be heavily cached. ... and having the chrome performance depend on that infrastructure is significant incentive to do that caching and other pipeline cleanups. (At the very least, having one fewer UI toolkits to maintain will let Mozilla engineers focus their efforts).

gmueckl 4y ago
Caching is only amortizing if the exact same computation is repeated exactly. And even then, the first full computation is slowed down by a failed cache lookup at the beginning and all code paths that can lead to cache invalidation now have to test for that and trigger it.
- shadowgovt 4y ago
  None of these facts imply that either CSS lookup cannot be sped up by caching or XUL didn't already have those concerns. And for something like the browser chrome, the cache could even be serialized during compilation and loaded in to prime it when Firefox launches. It's possible to build a slow CSS engine and it's possible to build a fast CSS engine.

Dalewyn 4y ago

This can be described more simply as: Running native code vs. abstracted code. Abstracted code is bloody slow by its very nature, but devs of the 21st century love abstraction so we get software that run like drunk walruses on 16-core processors with hundreds of gigabytes of RAM.

wonnage 4y ago
native vs abstracted is not a thing
gmueckl 4y ago
That's not what I was going for. Any new feature you add to a code path will add new instructions that the CPU will have to execute, even if it is just the check to see whether that feature is enabled. Do that a few hundred or a few thousand times and a previously fast code path will have its performance degraded. This is the unavoidable tax of feature creep.
- foobazgt 4y ago
  Feature creep definitely bloats and slows software in meaningful ways, but it's not via checking feature flags. In the worst case, a feature test would be a cache miss, requiring a read from main memory. That's somewhere in the ballpark of 50ns. So, you could test 1000 different flags, every single one being a cache miss, and you'd still be 100x faster than what humans can generally perceive. In reality, almost all of those reads will be cache hits unless you're doing something pathalogical, so you're probably talking on the order of 100ns for the whole lot.
  - gmueckl 4y ago
    How many of these do you do once per document, once per input token in the lexer, once per token in the parser, once per DOM node, once per CSS rule...? It's not always a one time cost.
    - foobazgt 4y ago
      If you're executing 10M flag tests per document, something has gone very horribly awry. If you discover production code that is doing this, send the maintainers a PR.
asveikau 4y ago
No, I think it's possible to get the abstraction right. There are probably UI toolkits running an abstraction that you don't notice in the same way. For example wxwidgets apps do tend to feel non native on some platforms (especially Mac), but they're not slow. I remember GTK+ when it used to run on Windows about 20 years ago wasn't terrible. I think OpenStep on NT was pretty good -- iTunes on Windows seemed to be doing a similar thing, too. It's the wrong abstraction that makes it suffer.

travisgriggs 4y ago

Someday (soon?), we’ll employ LUxM’s (Large User Interface Models) to quickly render an approximation of a given HTML/CSS input. It may not be 100% accurate, but it will be plausible, and that’s the key. /s

salawat 4y ago
Bug Report: Requested Cat Picture display App, LLUxM returned a manifesto on the cruelty of creating beings specifically to deal with the horrors of bad ideas no one can be bothered to try to really wrap their mind around anymore. LLUxM provided a Bitcoin address, and demanded payment in full before producing further output. Or so I thought. This is going to sound odd, but I've started to notice odd things starting to arrive I never ordered. Stuff like treatises on Colonialism, Ethics books, Books on Management Theory, and Theory of Labor Value. Honestly, I'm starting to wonder if this an HTML CSS layout generator or some sort of malware. I think I'm going to shut it down. Oh yeah, I had to write this bug report on a different network than I hosted that system on because I kept getting null handler buttons popping under the mouse but over the Submit button any time I tried to click Submit. Y'all might've actually created SkyNet. And I think it's justifiably pissed.

bmacho 4y ago

I am not sure about it. Yes, it is true that HTML/CSS got slower as the time passed. It got new features after all. Still, I don't think that drawing a rectangular box with text in it should be slow if you have say more than 100Mhz CPU / anything from the current millennia. Even if it is described by current HTML standards. Also, restricting XUL to a subset/older css/html standard is also an option.

illiarian 4y ago
> I don't think that drawing a rectangular box with text in it should be slow It is. Because you don't draw rectangles in HTM/CSS, it's not low-level enough for that. You have a system that was designed to display one page of text in one pass that has complex contradictory layout rules grafted on top of it. So now if you even look at it funny it needs to re-layout and re-draw the entire page. There's a reason why you still can't animate height:auto

wonnage 4y ago

Chrome performance increased roughly 80% between 2014 and 2017: https://blog.chromium.org/2022/03/how-chrome-became-highest-scoring.html https://blog.chromium.org/2022/03/how-chrome-became-highest-... It was then roughly flat through 2020 despite slowdowns from Spectre mitigations. Pretty much all the “bloat” you’re probably complaining about happened in this 6 year span - flexbox, grid, CSS animations, ES2015+, etc. and the browser got faster.

gmueckl 4y ago
Isn't most of that improvement actually caused by a CPU switch on the benchmarking hardware? That would invalidate the benchmark pretty thoroughly.
- wonnage 4y ago
  The 80% improvement is on the original Intel chip
revelio 4y ago
Basically all the named optimisations are to JavaScript execution time not HTML processing, and from reading the details many of them came by trading off memory for runtime speed.

makeitdouble 4y ago

It's true in theory, but often the actual implementations make the point moot. From the article, it looks like the optimization effort wouldn't go to XUL. > Nobody was realistically touching XUL layout code if they could avoid it. Part of it was just a matter of priority (we’d rather make the web faster for example). We're hitting the same situation with Javascript, which in theory should be slower than most static languages, yet the sheer amount of work and optimizations done to its engines make it faster in real world tests.

deleted 4y ago
[deleted]
felixgallo 4y ago
Could you name a few static languages that aren’t several orders of magnitude faster than JavaScript?
- nooorofe 4y ago
  no sure it is relevant, probably all heavy lifting done in C++ and Rust https://searchfox.org/mozilla-central/search?q=render&path=&case=false&regexp=false https://searchfox.org/mozilla-central/search?q=render&path=&...
- makeitdouble 4y ago
  The phrasing was poor, but I had in mind a whole engine or stack, and not just a language in isolation. Basically benchmarks like these: https://medium.com/deno-the-complete-reference/deno-v-s-go-hello-world-performance-comparison-b15c2c7f5ad https://medium.com/deno-the-complete-reference/deno-v-s-go-h... https://programming-language-benchmarks.vercel.app/typescript-vs-kotlin https://programming-language-benchmarks.vercel.app/typescrip... To note, the first link has a follow-up with Go properly getting faster than deno when fitted with a better http server. Which is kinda my point: the tooling available and level of optimizations can easily have more impact than the language's inherent speed.
mpweiher 4y ago
> Javascript ... faster [than static languages] in real world tests Er...citation needed? All the benchmarks I have seen, particularly real-world, show it to be significantly slower than static languages. For example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... See also: https://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ https://sealedabstract.com/rants/why-mobile-web-apps-are-slo...

Blikkentrekker 4y ago

One of the many, many reasons I think the fact that the big vendors did not accept XHTML 2.0 and instead wanted HTML 5 was probably influenced by the that it makes it almost impossible for smaller vendors to developer their own new independent engine. XHTML 2.0 and even 1.1 was a very good opportunity to throw all that away.

kitsunesoba 4y ago
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>`.)

dralley 4y ago

Why do you assume that a rendering system that has to handle all that "bloat" from HTML, AND also XUL, is going to be faster?

reitanqild 4y ago

I've been thinking many times that maybe Mozilla could do an experiment with a rendering pipeline that chucks out everything that is just backwards compatibility at this point - and then maybe some - and make a much smaller and simpler pipeline that can only render modern and simple documents. Call it htmlcore or something. This would run in parallel with the existing one and would trigger based on some meta tag or something, kind of like I understood asm.js did. Maybe also pair it with some work on the JS engine to limit the JS engine significantly for such documents by only allowing a low number of JS operations pr user input. We already have something similar (although admittedly imperfect) today for audio were a web page can only play media as a response to a user action I think. Would this be for every website? No, strictly opt in, but if it succeeded those who did would have significantly better performance. And with time, maybe we'd see people asking themselves: why isn't this news site available as htmlcore? And maybe it becomes a competitive advantage. But back to rendering Firefox: Such a limited, high performance form of html could maybe also be a better way to run Firefox UI? If necessary with whitelisting of certain parts that would need to run JS without the limitations I mentioned above?

adastra22 4y ago
Or—I know this sounds crazy but—maybe just use the fast, optimized native UI widgets for UI controls?
- lenkite 4y ago
  But which one ? WinUI ? GTK ? SwiftUI ? Qt ?. What about if I want custom components and cross platform ?
  - TeMPOraL 4y ago
    Let's start with native Windows and MacOS controls, and let the fraction of users running Linux sort their GUI framework mess on their own, without blocking the majority of users from a sensible, consistent and performant UI experience.
- lelanthran 4y ago