W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2018

Re: [csswg-drafts] Why argue against features based on performance?

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Fri, 01 Jun 2018 17:22:20 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-393949645-1527873739-sysbot+gh@w3.org>
> 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.)

GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2731#issuecomment-393949645 using your GitHub account
Received on Friday, 1 June 2018 17:22:26 UTC

This archive was generated by hypermail 2.3.1 : Friday, 1 June 2018 17:22:26 UTC