CSS has a containment property whichs sole purpose is to improve rendering performance.
So, first, we develop an abstraction so developers don't have to worry about implementation details like performance. Then, as soon as we realise that our abstractions are (obviously) dog slow, we add more stuff to make them fast again and have developers worry about that instead.
At this point, we might as well ship websites as compiled binaries.
The contain property is more about exposing what we already had with overflow: hidden; or display: inline-block; - properties that have more or less existed since the early days of CSS - but abstracted in a more readable and/or understandable way instead of being a "hidden" side-effect.
contain: content; = overflow: hidden;
contain: layout; will disable child element margins from collapsing, a trick previously doable with display: inline-block;.
@MerriNet Not saying you're wrong, but I just went by what the MDN said: "The aim of the CSS containment module is to improve performance of web pages by allowing the browser to isolate a subtree of the page from the rest of the page."
What I said is that these performance features have existed in CSS for 20+ years. You did need to know to use overflow: hidden; if you wanted a well performing collapse/expand animation.
The performance worry has always been there. You worry about perf no matter what you use or do.
There are far more idiotic things happening on the web space. Just look at React. It is the best dev time waster to perf and size optimizations, and people still keep using it.
@fell For a long time I have not had a situation, in which I crafted some CSS, that made a website slow. Actually it is pretty amazing, how fast modern browser rendering engines are. Websites with sane CSS will not face this issue, is what I think. Of course, we live with a web, in which sane CSS is an exception, not the rule.
@zelphirkaltstahl Try browsing the web on a 10 year old device and you will see how slow it can be. I don't mean this personally towards you, but everyone. Developers usually have expensive hardware, which makes them blind for performance. Not everyone can affort the latest hardware. 7.63% of internet users¹ are still using Android 7 or older. You can barely even use the web on those devices. And if you assume a total number of 5.3 billion internet users², that makes over 400 million people who are stuck with the experience of the dusty 10 year old backup phone in your drawer.
Please, pay attention to performance and don't just say: "Looks fast enough". Always use an older device to test.
@fell That's actually a good point. We should more often try with an older device. I personally have an X200, so pretty old, but I also don't allow much JS to run with that machine, since it is my free-software-only machine. I guess I also often self-select myself out of visiting bloated websites. But the point still stands for normal people, who want to browse the web with all its stuff. I am not so sure though, that excessive CSS is to blame. I think more often JS is to blame.
But as an example, I've noticed the blur effect is becoming popular. Now, blurring is actually a remarkably expensive operation because every pixel must be blended with all their neighbors. It also creates synchronisation issues because whatever is blurred must be rendered before the blur operation. It's a worthy tradeoff when used well, machines are certainly powerful, but older (or new but cheaper) devices might struggle with this.
@alextually Just that #JavaScript isn't compiled but interpreted and horribly slow. But I believe the slowness is not so much because of the language, but because of the way people are using it.
Seriously though, imagine an entire web application packed into a single 1 MB #WASM package that just pops up as soon as you open it. And I mean no HTML, no CSS, just one package. Internet speeds are as fast as disk storage was a few decades ago. There is honestly no technical reason as to why applications need to be installed locally.
Well, except everything that makes up the corporate mess we call the modern web, and the fact that applications are hundreds of megabytes for no good reason other than lack of effort and expertise.
@fell The idea of having compiled websites (or single pages) as a bundle is compelling.
It would be a bliss being able to share technical/scientific articles with interactive simulations/widgets in a sort of self-contained web bundle file, instead of print-ready-but-boring PDF files.
However, I wouldn't say that >=1MB is acceptable for most cases, except for complex apps. I'd also like to keep the ability to choose between SPA and MPA.
Add comment