Csswg-drafts: Why argue against features based on performance?

[danegraphics]

I'm not sure if this is the place for this question, but I couldn't think of a better place to ask.

When reading about desired CSS features, I often find that the most common argument against one or another feature suggestion is "performance" (my interpretation of "performance" is the CPU load and/or the render time of running the CSS on a client's computer).

However, I often do not understand the argument of performance because, most of the time, the designer is going to implement the feature regardless, even if it requires javascript to implement.

When it comes to accomplishing a desired design, the choices for the designer are either a javascript implementation, a CSS implementation, or just not accomplishing the desired design altogether, and most designers, including myself, usually find the latter suggestion to be completely unacceptable (What can I say? We want our dream interface).

In my experience, javascript always has worse performance than native CSS, to the point that the lag of the javascript is actually _visible_ for most javascript implementations of what could be a simple (user-side-wise) and intuitive CSS feature.

So if we're talking about the performance of the website as it loads and runs, then, at least for the simpler more intuitive feature suggestions, a CSS implementation will always be superior in terms of performance. In fact, the reason most designers ask for a pure CSS implementation is FOR the sake of performance.

For these reasons, I do not understand the arguments against simple and intuitive CSS features due to "performance issues", especially now that computers are getting faster and faster.

So am I misunderstand what is meant by "performance" in these discussions? Or is there an inherent difference in how CSS and javascript run that make javascript more lightweight somehow (despite always being laggier than CSS)? Or perhaps there is something else I am missing?

---

_An example would be the idea of a parent selector. Thankfully we're finally getting the :has() pseudo element, but the reason it has been put off for so long was this argument of performance._

[tabatkins]

However, I often do not understand the argument of performance because, most of the time, the designer is going to implement the feature regardless, even if it requires javascript to implement.

Yes, that will happen if the feature is important enough to the author. And that's okay! There are a million things someone might want to do on a page already, that we'll never be able to address in built-in stuff and the user will have to use scripting to achieve; this is just one more.

The issue, tho, is that if we build it in, people will use it more. Not just people who are really convinced they need this particular thing, such that they're willing to seek out (or write) a JS library to achieve it; other people who think the feature is just kinda neat will reach for it. It will be used way more often than if you have to write it yourself.

And if the feature is badly-performing, that means a lot of pages will have bad performance. Whereas in the current situation, only the page that really needs it will have bad performance (and even then, since they know their very specific requirements, it's very likely they can write something much more optimized to their exact needs, and thus have perfectly fine perf), and everyone else will use existing good-perf workarounds, or choose to do something else instead.

So if we're talking about the performance of the website as it loads and runs, then, at least for the simpler more intuitive feature suggestions, a CSS implementation will always be superior in terms of performance.

This is not always true. CSS has a limited feature budget, so we try to make things as multi-purpose as reasonably possible, and a large set of existing features that new things have to interoperate with. New features end up racking up quite a bit of complexity debt to make sure they fit into the ecosystem well. A custom-written script solving someone's specific needs, on the other hand, often doesn't need to worry about all of that, and can ignore a lot of sanity-checking and edge-cases that CSS has to worry about.

For example, Flexbox pays a relatively significant performance tax to make sure it works properly with mixed writing modes (mixing English/Arabic/Chinese/etc on a single page), and to make sure that percentages work in an expected fashion in as many situations as possible. You can write a simpler version of Flexbox in JS that only solves English-language needs and doesn't care as much about %s, and have it run decently faster than the built-in Flexbox. (The only real problem today is that it won't interoperate well with CSS sizing in general; the Houdini Layout API solves that for us.)

[danegraphics]

@tabatkins

A custom-written script solving someone's specific needs, on the other hand, often doesn't need to worry about all of that, and can ignore a lot of sanity-checking and edge-cases that CSS has to worry about.

OOOoookay, that makes a lot of sense! Thanks for clearing that up!

The issue, tho, is that if we build it in, people will use it more.

Ah... I see. You wish to avoid _abuse_ of the feature. It isn't simply that it's a _performance_ problem, it's that it's a performance problem that would likely end up _widespread_. So while a feature may work well at accomplishing many tasks that other CSS can't accomplish on its own, the feature may actually be so flexible that people will use it where it isn't necessary (where other CSS or html structure is possible to accomplish the same task), and end up taking a performance hit because of it.

Is that what you mean?

[tabatkins]

Yeah, I mean, we can't stop people from making slow pages. But at least if they have to do it themselves, they're being slow on purpose, and that doesnt' spread to other people. (Usually...)

Whereas if the feature is fast, let people "misuse" it. You can do lots of cool stuff by "abusing" a feature for things it was never designed for. ^_^

[jonjohnjohnson]

Firstly, this exchange was a joy to read. Secondly, maybe a condensed version of the rationale above could go into https://wiki.csswg.org/faq? Even if folks within the wg already work with it in mind.