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

111–120 of 165 posts

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

#111

Post by throw_m239339 »

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 the entire dev community was gazlit into believing that "tables" for layout were bad. Tables weren't bad, CSS wasn't just good enough, otherwise Flexbox or Grid would not be needed.

Flexbox considerably simplified CSS layout. The people who never had to use a single float attribute in their style declaration cannot fathom that.

CSS, the way it was designed, has been terrible for a long time and a thorn in the side of generations of web developers, but nobody want to acknowledge that. IF there is one thing the web failed at, it's absolutely CSS, from its syntax to the way it works in conjunction with HTML And Javascript.

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

#112

Post by jonorsi »

andrewingram wrote: post #20
jonorsi wrote: post #12

This is an apples to oranges comparison -- a run-time compiled stylesheet vs. a statically-generated stylesheet. Styled Components has options for statically-generating their stylesheets ( https://styled-components.com/docs/advanced#server-side-rend... ), so why wouldn't you compare those?

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 eventually provide the tools to do so.

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

#113

Post by codegrappler »

jfengel wrote: post #26
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 t…

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.

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

#114

Post by developer2 »

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…

The reason tables for layout were so bad was that the table as a whole couldn't be rendered (laid out) properly until every cell was fully rendered first, including images with unspecified width/height attributes as well as dynamic cell dimensions based on free-flowing text, etc. Floating div tags still cause redraws for containers with content requiring dimensions to be determined at runtime, but at least something would display. It was also easier to see which divs were causing redraws because their dimensions were not fixed, and thus developers could focus on those specific regions to try and add fixed dimensions.

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

#115

Post by jonorsi »

NegativeLatency wrote: post #13
jonorsi wrote: post #12

This is an apples to oranges comparison -- a run-time compiled stylesheet vs. a statically-generated stylesheet. Styled Components has options for statically-generating their stylesheets ( https://styled-components.com/docs/advanced#server-side-rend... ), so why wouldn't you compare those?

Might not be a fair comparison, but there are people who are looking at changing up how their css is written so it makes sense to be aware of the differences in performance.

Definitely should be aware, and I would highly recommend static files over large JS apps. The options are there to have both now with frameworks like Gatsby and Next.

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

#116

Post by enumjorge »

codegrappler wrote: post #113
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…

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?

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

#117

Post by throw_m239339 »

developer2 wrote: post #114
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…

The reason tables for layout were so bad was that the table as a whole couldn't be rendered (laid out) properly until every cell was fully rendered first, including images with unspecified width/height attributes as well as dynamic cell dimensions based on free-flowing text, etc. Floating div tags still cause redraws for containers with content requiring dimensions to be determined at runtime, but at least something…

edit: My comment sounds a bit angry, but it's not directed at you personally, so keep it in mind ;)

> The reason tables for layout were so bad was that the table as a whole couldn't be rendered (laid out) properly until every cell was fully rendered first, including images with unspecified width/height attributes as well as dynamic cell dimensions based on free-flowing text, etc [...]

That was purely a limitation of the CSS rendering engines, it had absolutely nothing do to with table layout themselves, from a developer perspective. There is no reason this problem cannot/couldn't be worked out by CSS rendering engine developers. I get what you are saying, but it wasn't a good enough reason to dismiss tables entirely (and that wasn't the biggest reason used back then when "a list apart" writers decided that tables were cancer).

Floats were so good yet developers had to resort to CSS frameworks and grid frameworks for years in order to make working with CSS bearable? No, float positioning was horrible, un-intuitive and just a hack. Again, the culprit was CSS itself (and by extension the rendering engines), not the developer using tables.

The irony is that all these CSS frameworks were essentially tables re-implemented on top of "floating divs".

A good measure of whether a web spec is good or not, or pragmatic enough or not is how much effort developers go through in order not to use that spec directly. Generally, if using a framework on top of the spec to make that spec somehow useful is what most developers do, it means that the spec needs to be revised and improved in order to fulfil the needs of the developer, not the other way around. Obviously that doesn't apply to low level protocols like WebRTC and co, but CSS isn't a low level protocol, it was supposed to make web presentation easy, and it failed at it for decades. That's all I'm saying.

Just thank god we now have at the very least Flexbox and Grid. Which makes bootstrap and co completely redundant even for devs allergic to design.

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

#118

Post by joshwcomeau »

I think an important caveat here is that in a serverside-rendered context, linaria’s 70kb of CSS would be a bigger issue than styled-component’s additional JS. The page can’t render until it has downloaded the CSS.

Granted, many react apps aren’t serverside-rendered, so these numbers are still useful and interesting. But I would say that if performance is a priority, moving to an SSR solution (or away from React altogether) would have a way bigger impact on performance.

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

#119

Post by throw_m239339 »

lstamour wrote: post #50
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…

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

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

#120

Post by runarberg »

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 :)

Comparing Tailwind with Web Components might be a bit unfair. It is well known that Web Components have terrible dev ergonomics.

It would be more fair to compare with frameworks that work with scoped styles (such as Svelte or Vue’s single file components). Developing in these is also an excellent productivity boost.

Post reply on HN