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

21–30 of 165 posts

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

#21

Post by stevebmark »

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…

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.

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

#22

Post by mikewhy »

stevebmark wrote: post #21
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…

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.

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

#23

Post by z3t4 »

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 stuff, and that's where aka "single page app" have an advantage over full reloads. Measure things like click latency and re-render times!

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

#24

Post by rimliu »

stevebmark wrote: post #19
lwhi wrote: post #7

Earlier quoted context omitted.

I've never really been comfortable with the idea, as I was raised on the idea that separation of concerns is good thing. I think one of the main appealing aspects is the idea of never having a styling conflict with other components ever. Less macro-level management and organisation required. -- Edit: sorry, just realised you're talking about a specific implementation.

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 understanding under multiple wraps of abstraction.

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

#25

Post by hudixt »

stevebmark wrote: post #21
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…

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.

Added one more point on API. Also, you'll probably end up using one more library called classname for better classname management.

https://www.npmjs.com/package/classnames

In the end, I generally prefer to use tailwind + emotion. My goals usually is to save time and make system more consistent rather than perf gains, which isn't that much on new systems.

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

#26

Post by jfengel »

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?

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 that drives people to css-in-js. But I manage fairly large things and don't have too much grief with plain css.

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

#27

Post by stevebmark »

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 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 are a well established pattern.

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

#28

Post by nicoburns »

hudixt wrote: post #25
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.

Added one more point on API. Also, you'll probably end up using one more library called classname for better classname management. https://www.npmjs.com/package/classnames In the end, I generally prefer to use tailwind + emotion. My goals usually is to save time and make system more consistent rather than perf gains, which isn't that much on new systems.

Indeed. Worth noting that classnames is a tiny library.

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

#29

Post by Kiro »

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?

I love not having to come up with class names. That's it.

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

#30

Post by topspin »

Great effort and I have no dispute with the methodology. The conclusion, however, is naïve. Specifically this part:

"Great developer experience shouldn’t come at the expense of the user experience."

Great developer experience can conceivably deliver better user experience. A more capable, responsive and lower defect application that load 10% slower may be a net improvement.

I'm not arguing that CSS-in-JS actually delivers that. Only that load times aren't the only variable in the "user experience" equation.

Post reply on HN