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

91–100 of 165 posts

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

#91

Post by lwhi »

iaml wrote: post #86
lwhi wrote: post #75

Earlier quoted context omitted.

> For me, writing javascript that directly sets css properties based on state variables is a more powerful and clearer approach to managing dynamic styles than manually managing class names. I'd argue there's a lot more flexibility available if you choose to use classes. Sure, it's more complicated and involves more work; but to say it's less powerful just isn't true.

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

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

#92

Post by rajangdavis »

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`, );

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

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

#93

Post by lwhi »

stevebmark wrote: post #27
rimliu wrote: post #24

Earlier quoted context omitted.

Moving goalposts is not a concern either. CSS and Javascript are concerns, becaus HTML is of content/structure, CSS is for styling and JS is for behaviour. Of course somewhere along the road devs thought that HTML and CSS are to primitive to spend any time learning them properly, because of that they later found them to bee too complex and we ended up in the mess we are right now, when we try to hide the lack of unde…

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?

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

#94

Post by lwhi »

rimliu wrote: post #24
stevebmark wrote: post #19

Earlier quoted context omitted.

CSS and Javascript aren't concerns, they're technologies, and separation of technologies isn't a software engineering principle. "Concern" is pretty undefined in general. If anything, they're all part of the "view" concern. It's the same reason why JSX doesn't violate separation of "concerns."

Moving goalposts is not a concern either. CSS and Javascript are concerns, becaus HTML is of content/structure, CSS is for styling and JS is for behaviour. Of course somewhere along the road devs thought that HTML and CSS are to primitive to spend any time learning them properly, because of that they later found them to bee too complex and we ended up in the mess we are right now, when we try to hide the lack of unde…

I agree, I don't know why you're being downvoted.

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

#95

Post by gentleman11 »

hudixt wrote: post #18

A 4 year experienced react dev here. I have had decent time working with different styling I'll try to answer few common things for everyone's context Why even use CSS in JS? - SPA bundling usually loads all CSS at once and all styles collide. You need to be super good at naming stuff/or load CSS based on module. So your CSS will be conflicting, so scoping is helpful here. - Not having to jump from your component fil…

Whenever you talk to somebody about how ridiculous it is to need a preprocessor to do basic sane things in css, you hear about how “css isn’t designed for that, it’s better this way. Use a preprocessor!”. Preprocessors are a workaround, not “the way it should be.” There’s no good reason why a @media query can’t take a variable for a min-size value, it just makes things error prone. Yet, the css spec is so proud of itself it has declared that there will never be a css 4

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

#96

Post by dimal »

vpfaulkner wrote: post #36

My gripes with traditional CSS styling are: - Styles are global - Styles are targeted via brittle, untyped, and opaque "magic strings” basically. This means mistakes are more likely to be caught at run time than compile time. Eg, I wouldn't get a compile time error if I did `position: oops` or `class="oops"`. - Styles are often "far away" from their target which makes mistakes more likely; ie this deeply nested HTML…

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. calc() can handle some pretty complicated math. You can also do plenty of math in Sass.

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

#97

Post by [deleted] »

easrng wrote: post #83
lwhi wrote: post #76

Earlier quoted context omitted.

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.

I'd use CSS variables for colors and write another stylesheet, using the cascade so I only override the styles I need to.

[deleted]

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

#98

Post by daigoba66 »

dimal wrote: post #96
vpfaulkner wrote: post #36

My gripes with traditional CSS styling are: - Styles are global - Styles are targeted via brittle, untyped, and opaque "magic strings” basically. This means mistakes are more likely to be caught at run time than compile time. Eg, I wouldn't get a compile time error if I did `position: oops` or `class="oops"`. - Styles are often "far away" from their target which makes mistakes more likely; ie this deeply nested HTML…

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?

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

#99

Post by betoharres »

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?

React Native

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

#100

Post by [deleted] »

lwhi wrote: post #62
stevebmark wrote: post #19

Earlier quoted context omitted.

CSS and Javascript aren't concerns, they're technologies, and separation of technologies isn't a software engineering principle. "Concern" is pretty undefined in general. If anything, they're all part of the "view" concern. It's the same reason why JSX doesn't violate separation of "concerns."

I disagree. You're being obtuse. JavaScript is used for more than presentation.

[deleted]
Post reply on HN