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

141–150 of 165 posts

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

#141

Post by lwhi »

masswerk wrote: post #109
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.

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 li…

True, but I'm wondering how the CSS in JS users would implement this.

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

#142

Post by lwhi »

notoverthere wrote: post #81
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.

Switch the ` ` value to point to a high contrast stylesheet. Or alternatively, apply a class to the body tag – e.g. ` ` – and declare CSS rules accordingly. Specificity should take care of overriding the 'normal' style rules where needed.

Having to override styles that have random namespace tokens in the class names (via CSS in JS) is going to be difficult.

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

#143

Post by Keats »

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 wrote https://www.vincentprouillet.com/blog/using-sass-modules-typ... and a commit example: https://github.com/Keats/webpack-react-typescript/commit/978...

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

#144

Post by Keats »

paulintrognon wrote: post #40
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…

You can address points 1 and 3 via (s)css modules. But point 2 and 4 stand.

Point 2 is solved if you add TS to the css modules.

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

#145

Post by pentagone »

dheera wrote: post #42
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?

Considering CSS is Turing complete I suppose we could also do JS-in-CSS.

We actually do this at my company. Our user base is mostly security focused and browses with javascript disabled so we had to find another way to make reading a simple text with some pictures thrown in terribly slow for them. We like it so much that we are currently developing a server runtime for it called node.css. We are also working on a meta package manager based on this runtime so we can manage our dependencies on different package managers more easily.

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

#146

Post by andrewingram »

jonorsi wrote: post #112
andrewingram wrote: post #20

Earlier quoted context omitted.

You linked to server side rendering, not static extraction of styles, did you mean something else? The point of static extraction (something the current wave of new CSS-in-JS libraries seem to be focusing on), is to generate all the style sheets at build time and serve them as regular CSS files — so that your styles don’t inflate your JS bundles (a problem most older CSS-in-JS libraries have).

SSR would extract all the styles out for the styled components, but I guess now it would have an advantage as all the html/js would be as well. My point is, the comparison seems more “js runtime stylesheets” vs “regular static stylesheets.” Styled Components, or CSS-in-JS, isn’t really the main focus here. There are options to get the static stylesheets generated, and I predict most CSS-in-JS frameworks will eventual…

With conventional CSS-in-JS solutions like emotion and styled-components, SSR with these libraries still extracts the stylesheets at run-time, so it's not static extraction -- where the extraction is done at build-time. And your style definitions still live in your code bundles -- inflating the size.

Both emotion and styled-components have dabbled in supporting static (build-time) extraction, but it's actually a hard problem to solve when you have such flexible APIs. The libraries that have cropped up to support this notion of near-zero runtime CSS-in-JS (Linaria, Astroturf, vanilla-extract, and more) do so by providing tighter constraints surrounding what you can and can't do.

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

#147

Post by o_m »

stephen wrote: post #67

We have a "write tachyons/tailwinds CSS-in-TypeScript" project [1] that can sit on top of any CSS-in-JS runtime (emotion and fela are both supported). I'm hoping to eventually find one of these build-time CSS-in-JS frameworks that is smart enough to partially eval ~80% of our ` ` expressions to be zero runtime. And, if/when this happens, do this as a seamless upgrade to our existing codebases, i.e. without any lines…

Why not use only Tailwind at that point? Then you always have no runtime.

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

#148

Post by BatteryMountain »

throw_m239339 wrote: post #111

It's funny how we are going from one orthodoxy to another, from "separate logic from presentation at all cost" to "inline all css directly in your HTML tags". It reminds me the era when devs were chastised for using tables for layout, and using floats was deemed the right way to do things, when both techniques were essentially just hacks with both their strengths and weaknesses (overflow:hidden anyone?), but somehow…

I recently made a simple layout with flexbox with about 60 lines of css (header, content area with two sidebars and footer) that would've taken either 500 lines of css or had to pull in whole css frameworks to do it. Flexbox is pretty close to what we are used to on desktop applications.

Using almost no absolute pixel sizes and none of the usual suspects (clearfix, floats, position: absolute, z-index: 9999 ...none of that crap).

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

#149

Post by jonorsi »

andrewingram wrote: post #146
jonorsi wrote: post #112

Earlier quoted context omitted.

SSR would extract all the styles out for the styled components, but I guess now it would have an advantage as all the html/js would be as well. My point is, the comparison seems more “js runtime stylesheets” vs “regular static stylesheets.” Styled Components, or CSS-in-JS, isn’t really the main focus here. There are options to get the static stylesheets generated, and I predict most CSS-in-JS frameworks will eventual…

With conventional CSS-in-JS solutions like emotion and styled-components, SSR with these libraries still extracts the stylesheets at run-time, so it's not static extraction -- where the extraction is done at build-time. And your style definitions still live in your code bundles -- inflating the size. Both emotion and styled-components have dabbled in supporting static (build-time) extraction, but it's actually a hard…

SSR (at least with Gatsby) extracts the styles at build-time.

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

#150

Post by 1_player »

The_rationalist wrote: post #68
Kiro wrote: post #29

Earlier quoted context omitted.

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

Yay let's loose semantic meaning aka understandability and reuse

Nothing stops you from adding a semantic class name, if you need one. Let me remind you that a tag can have more than one class.
Post reply on HN