Item — HN Reader

> DevTools now gives you the list of all the CSS selectors that got calculated by the browser engine during this recalculation operation.

This is cool. The rest of the article IMHO is just an example runthrough of micro-optimisations that nobody reading should adopt into their own practice _unless_ their own perf analysis indicates a problem. It's incredibly unlikely that real-user-experienced UI slowdowns are due to stuff like this.

4 comments

I helped out with this post a bit - The examples he goes through are taken from actual performance investigations done on Microsoft apps that contributed to this feature being developed.

It’s not trying to say everyone should adopt those optimizations, but intended to be a hands-on “try it out” without the reader needing to have their own app handy :)

Super! And thank you. I love this granularity of tooling now. it’s overwhelming, if anything.

To my original comment, I think I’m just naturally very wary of people losing themselves in the weeds without real cause. If there’s genuine slowdowns being experienced, absolutely dive into it. There are cautionary tales here though. Like when one makes an optimisation based on current browser implementations, only to have it be slower within a couple release cycles because the browsers have updated their implementations. Lots of this occurred with js looping idioms when es5 gained broader usage. All wasted time, in the end. IMHO it’s best to stick to idiomatic patterns and those espoused in the specs themselves. 99% of the time, that’ll cover you.

anytime we can stop the death by a thousand cuts is good news to begin to shape best practices and inform future choices. It's probably more the in aggregate threat than any single choice.

Is there any reason the blog post didn't have a link to the demo site?

I think some of the shown examples exhibit dark patterns in CSS authorship. For instance, unneccessary nesting happens when you use a CSS preprocessor such as LESS or SASS and basically structure/nest your CSS following the structure of your HTML (instead of writing a CSS file orthogonal to the HTML structure). That will generate bad and bloated CSS code which is slow. This habit exists since >10yrs (as LESS/SASS date back for around ~>10yrs).

The amount of trouble and complication front end devs make for themselves because they refuse to learn CSS is incredible. I've literally heard people call it "raw CSS" as if they were toggling in instructions on the front panel of a minicomputer.

Backend developers can be even worse - I’m thinking of someone who had a Very Serious Java framework they used in business apps, which generated many thousands of lines of redundant CSS basically styling every element so they could avoid learning how selectors or positioning worked. The best part was that this was a bottleneck for every project but they kept insisting it was easier.

It’s a question of respect: if you think CSS is a toy language for your inferiors, you probably aren’t going to learn it very well because you’re not going to be receptive to learning the designers’ intent.

I've never heard "raw CSS" with that connotation. I've usually heard it used to point out that they're writing .css files that are getting directly referenced and aren't getting generated or compiled in a build pipeline, because CSS with extra tooling is so common (for good productivity reasons) these days.

As CSS is a declarative non-turing-complete (in any practical sense) language without any specification for performance details, it’s a job of a CSS engine to care about performance of CSS written in this or that way. Blaming developers for not being aware, bothered or disciplined enough to Use It Properly is antitethical to its design and nature.

That doesn't imply you shouldn't use the existing features of the tool to your advantage. I get the lack of spec, but this isn't 2001 anymore. You can create rules in accordance to general relationships, and not strictly parent child ones.

What if you don’t want general relationships and instead design specific blocks as desired? Coincidentally similar geometry doesn’t mean that it must become a local standard with a name and be factored out. It’s actually a bad practice named “fragile base class”.

This is totally it. Less is where I developed a complete aversion to nesting.

That's kind of the point of the article though right?

"Here's a new dev tool that can point to problems, and here's how you fix it"

That's what the article says already

> In practice, does it matter? Maybe. This heavily depends on the web page