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

101–110 of 165 posts

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

#101

Post by runarberg »

rajangdavis wrote: post #92
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`, );

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 less clear.

So in honestly I don’t see how setting a CSS custom property in JavaScript as lacking in expressing the intent.

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

#102

Post by Aeolun »

runarberg wrote: post #85
rajangdavis wrote: post #82

Earlier quoted context omitted.

To be clear - when I need to toggle a basic state with a class or set of classes, that is the strategy I use. Where that technique fails is when you have hundreds of possible values that can occupy a given state. If I want to set the rotation or opacity for a control and I want to use a range of values, there is nothing native in CSS to allow me to do that. You can use SCSS to dynamically generate the CSS class decla…

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.

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

#103

Post by mmgutz »

MatekCopatek wrote: post #5

Can someone explain the appeal of CSS-in-JS? I've used scoped styling in .vue components extensively, at a quick glance it seems to offer similar benefits (lives right in your component and is scoped to it), but most importantly it can be extracted to a plain CSS file when building frontend assets. Is there something extra these React libraries do that prevents them from doing this?

An underlying appeal of React is it's just Javascript (yes even JSX templates). CSS-in-JS gives you the same flexibility and control over CSS from Javascript. No need to learn SASS, Less etc. It replaces the functionality those utilities with just Javascript. No setup required.

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

#104

Post by Aeolun »

lwhi wrote: post #91
iaml wrote: post #86

Earlier quoted context omitted.

> there's a lot more flexibility available if you choose to use classes That is simply not true. Apart from what was described in the post above, in JSS frameworks such as styled-components, you usually have ways to hook directly into css parser, allowing you to implement custom expansions, replacements or basically whatever logic you want. This is not possible unless you write your own language and transform it to c…

We'll have to agree to disagree.

CSS is not a programming language.

I find it hard to believe you think you can do more with plain CSS than with the full power of the Javascript programming language.

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

#105

Post by dimal »

daigoba66 wrote: post #98
dimal wrote: post #96

Earlier quoted context omitted.

CSS modules with TypeScript solves the first three items pretty neatly. You write CSS that lives alongside tour component, then import the file into your component and apply the classname to your elements. It compiles to unique classnames that cannot conflict with any others. And with TS, you’ll get a compile error if you use a class that doesn’t exist. The last point is possible either with CSS vars or Sass vars. ca…

Are there any good examples or tutorials for using CSS modules and TypeScript as you described?

I don't know of any full tutorials that cover both, but this is an ok rundown on how to use them in JS: https://css-tricks.com/css-modules-part-1-need/

This is the webpack loader that generates type def files: https://github.com/seek-oss/css-modules-typescript-loader

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

#106

Post by hmsimha »

mmgutz wrote: post #103
MatekCopatek wrote: post #5

Can someone explain the appeal of CSS-in-JS? I've used scoped styling in .vue components extensively, at a quick glance it seems to offer similar benefits (lives right in your component and is scoped to it), but most importantly it can be extracted to a plain CSS file when building frontend assets. Is there something extra these React libraries do that prevents them from doing this?

An underlying appeal of React is it's just Javascript (yes even JSX templates). CSS-in-JS gives you the same flexibility and control over CSS from Javascript. No need to learn SASS, Less etc. It replaces the functionality those utilities with just Javascript. No setup required.

For anyone capable of using React, there's no barrier to 'learning' sass (you can be productive with it in about 30 seconds). Admittedly there might be some additional work around configuring compilation to work with the rest of your build and dev processes, etc. But sass in it's most basic usage (nested selectors) is really what CSS should have been.

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

#107

Post by stevebmark »

lwhi wrote: post #93
stevebmark wrote: post #27

Earlier quoted context omitted.

I don't think it's that clear cut, you can define all sorts of behavior with both HTML and CSS, and there's no semantic meaning in ` `, which itself changes page style due to its layout properties. I don't know what goalposts are being moved, React/css-in-js have never violated separation of concerns. After all, css-in-js produces CSS, and React produces HTML. Separation of technologies isn't a principle, but DSLs ar…

Is complexity a drawback?

What?

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

#108

Post by Supermancho »

lwhi wrote: post #76
jfengel wrote: post #26

Earlier quoted context omitted.

I'm afraid I don't get it either. To me, the big disadvantage of css-in-js is that the browser doesn't display it neatly. If I write plain CSS, it's easy to make changes right in the browser and have it react instantly. Or I can make them in the .css file, and webpack (or whatever it is) will automatically redisplay them without having to restart the app. Perhaps if I had much larger projects I'd see more headaches t…

Imagine you need to implement an alternative stylesheet for people with increased visual needs (e.g. high contrast). How would you go about doing this? -- Edit: to the person who downvoted me for asking a question. Classy.

HN randomly mods posts. Don't assume malice.

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

#109

Post by masswerk »

lwhi wrote: post #76
jfengel wrote: post #26

Earlier quoted context omitted.

I'm afraid I don't get it either. To me, the big disadvantage of css-in-js is that the browser doesn't display it neatly. If I write plain CSS, it's easy to make changes right in the browser and have it react instantly. Or I can make them in the .css file, and webpack (or whatever it is) will automatically redisplay them without having to restart the app. Perhaps if I had much larger projects I'd see more headaches t…

Imagine you need to implement an alternative stylesheet for people with increased visual needs (e.g. high contrast). How would you go about doing this? -- Edit: to the person who downvoted me for asking a question. Classy.

This is, what ``is for. (Using JS, you can switch between default and alternative stylesheets by setting their "disabled" attribute accordingly.) This mechanism also allows a user to (pre)select a stylesheet in the browser.

Sadly, Chrome doesn't support this standard (it has been around for a while and is in HTML4, HTML Living Standard, CSSOM). But you can work around this by JS, see above.

(Edit: It's for things like this that you still want a menu bar for your browser.)

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

#110

Post by acdha »

lwhi wrote: post #76
jfengel wrote: post #26

Earlier quoted context omitted.

I'm afraid I don't get it either. To me, the big disadvantage of css-in-js is that the browser doesn't display it neatly. If I write plain CSS, it's easy to make changes right in the browser and have it react instantly. Or I can make them in the .css file, and webpack (or whatever it is) will automatically redisplay them without having to restart the app. Perhaps if I had much larger projects I'd see more headaches t…

Imagine you need to implement an alternative stylesheet for people with increased visual needs (e.g. high contrast). How would you go about doing this? -- Edit: to the person who downvoted me for asking a question. Classy.

You can specify alternative style sheets and even get some standard browser UI:

https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative...

I’ve implemented that two ways: having JavaScript pop the alternative attribute off for all but the desired style sheet or simply using a top-level class to modify the relatively few things we were customizing. Back in the day, I used SCSS but CSS Variables have matured to the point where you can do an awful lot that way, too.

Post reply on HN