Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Real-world CSS vs. CSS-in-JS performance comparison

pustelto.com

Post reply on HN
Print view View original

121–130 of 165 posts

Re: Real-world CSS vs. CSS-in-JS performance comparison

#121

Post by runarberg »

Aeolun wrote: post #102
runarberg wrote: post #85

Earlier quoted context omitted.

I see what you mean. For that I would use a CSS custom property: .rotatable { transform: rotate(var(--rotation-angle)); } ...and set it directly with JavaScript document .querySelector('.rotatable') .style.setProperty( '--rotation-angle', `${angle}deg`, );

That’s not a very elegant solution in any front-end JS framework. Calling directly to css/element styles is generally strongly discouraged.

Any insight into why that is discouraged?

Also I explain on a sibling thread that there is a fundamental difference between setting a custom property (like I do here) and setting a specific style value. While I do see how the latter can be problematic as there are no hints to the changed style in the CSS file, the former does not have that issue, particularly if you name the property with a hint to the dynamic nature if it.

Re: Real-world CSS vs. CSS-in-JS performance comparison

#122

Post by girvo »

enumjorge wrote: post #116
codegrappler wrote: post #113

Earlier quoted context omitted.

For us the big win is branded sites. We have a white labeled product that is customizable for each client. No code deploys needed to add a new client. Values live in a db table and get pulled in dynamically based on the url subdomain.

Honestly curious, couldn’t you achieve something similar with style sheets, where you determine what .css file to serve based on the subdomain?

Yes, and using CSS Custom Properties/the var() function you can even keep that branding file as small as said table. Could even build it dynamically, if one wanted.

Re: Real-world CSS vs. CSS-in-JS performance comparison

#123

Post by girvo »

mikewhy wrote: post #22
stevebmark wrote: post #21

Earlier quoted context omitted.

CSS modules solves all of these problems (except the separate file), and also lets you write vanilla CSS, and not have to hack around the limitations of css-in-js. Dynamic styles are easy with React's `css` prop, or simply passing in an additional class name.

React doesn't have a CSS prop.

I think they've assumed `styled-components` is default?

Re: Real-world CSS vs. CSS-in-JS performance comparison

#124

Post by swilliamsio »

gherkinnn wrote: post #51
diob wrote: post #39

Earlier quoted context omitted.

I've really enjoyed tailwind after using styled for a while. At least for my applications, the computers my users run on can't handle the performance implications of styled. But beyond the performance, I legitimately build faster using tailwind. I also find it easier to understand the components others build as well.

Completely agree. This whole discussion feels silly after a day building things with Tailwind. The system, defaults, docs and tooling are excellent. And dev speed is ludicrous.

Haven't heard of this until now. Looks like a cleaner version of Bootstrap?

Re: Real-world CSS vs. CSS-in-JS performance comparison

#125

Post by earthboundkid »

throw_m239339 wrote: post #119
lstamour wrote: post #50

Earlier quoted context omitted.

"Styles are global" is changing :) https://youtu.be/jUQ2-C5ZNRc?t=683 Looks like the spec is at https://drafts.csswg.org/css-scoping-1/ with examples like https://drafts.csswg.org/css-scoping-1/#example-f1503361 and more details at https://css.oddbird.net/scope/ Still experimental of course, but could be very useful if implemented alongside Shadow DOM. Note this isn't 2012's scoped CSS: https://caniuse.com/style-scop…

CSS scoping without a hacky third party framework is long overdue. Web components largely failed at this point though, the spec needs to be rewritten from scratch to be more pragmatic. People have been using React and Co for more than a decade now, spec writers certainly have enough hindsight as to how people practically program front-end applications.

Web components are a great brand for a collection of mostly awful APIs. Shadow DOM in particular should have just been a CSS property from the start. Glad to see someone starting to recognize this.

Re: Real-world CSS vs. CSS-in-JS performance comparison

#126

Post by mook »

throw_m239339 wrote: post #119
lstamour wrote: post #50

Earlier quoted context omitted.

"Styles are global" is changing :) https://youtu.be/jUQ2-C5ZNRc?t=683 Looks like the spec is at https://drafts.csswg.org/css-scoping-1/ with examples like https://drafts.csswg.org/css-scoping-1/#example-f1503361 and more details at https://css.oddbird.net/scope/ Still experimental of course, but could be very useful if implemented alongside Shadow DOM. Note this isn't 2012's scoped CSS: https://caniuse.com/style-scop…

CSS scoping without a hacky third party framework is long overdue. Web components largely failed at this point though, the spec needs to be rewritten from scratch to be more pragmatic. People have been using React and Co for more than a decade now, spec writers certainly have enough hindsight as to how people practically program front-end applications.

People have been using XBL in Mozilla before all the web components work started, so… I wouldn't hold my breath.

Looking it up, archive.org says it's been over 20 years… https://web.archive.org/web/20001218094100/https://www.mozil...

Re: Real-world CSS vs. CSS-in-JS performance comparison

#128

Post by rajangdavis »

runarberg wrote: post #101
rajangdavis wrote: post #92

Earlier quoted context omitted.

And that's why I wrote: If you want to have a range of applicable values for some CSS property or state-based styling, CSS-in-JS can be a good tool for expressing that as opposed to writing JS that updates some styling declaratively

I see. There might be a difference in opinion. I think there is a fundamental difference in setting style properties in JS and setting CSS custom properties (even though CSS custom property is a style property). The main difference is that it is clear from the CSS that this property is dynamic and can be expected to change. If you overwrite a style attribute (e.g. `element.style.transform = "rotate(50deg)"`) this is…

The main use case highlighted in the article is React and that is the use case that I am speaking to.

With React, you don't modify the DOM directly, so the use case you have laid out is not applicable.

With that in mind, you are still free to use the CSS custom property with React, but if you want to have multiple transformations across multiple parts of an application, it's a lot simpler to use CSS-in-JS to generate styling based on state.

The use case you have brought up should work well with vanilla js/jquery; however, the context of the discussion is rooted in front-end libraries and the popularity of CSS-in-JS, so I am not sure how custom properties are relevant.

Re: Real-world CSS vs. CSS-in-JS performance comparison

#129

Post by pineconewarrior »

zoover2020 wrote: post #65
gherkinnn wrote: post #51

Earlier quoted context omitted.

Completely agree. This whole discussion feels silly after a day building things with Tailwind. The system, defaults, docs and tooling are excellent. And dev speed is ludicrous.

Fully agree. It's usually the people that have never worked with it that share their opinion, always ending with "why do we need this" Can encourage others to give it a try as well. Dev productivity through the roof indeed :)

Trying to get my team to consider the switch from Bootstrap to Tailwind. All of this talk makes me jealous

Re: Real-world CSS vs. CSS-in-JS performance comparison

#130

Post by pineconewarrior »

z3t4 wrote: post #23

I'm not a fan of web frameworks such as React and CSS in JS, but to be fair, you should not stare blindly on first-time-load times! Imagine if you would include download and install time when you measured native app performance... You should also take into account repeat use performance! While most "users" will just load the app once and leave, those who actually use the app will spend hours clicking around and doing…

This is almost certainly a result of the recent Google "core web vitals" update.
Post reply on HN