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

151–160 of 165 posts

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

#151

Post by andrewingram »

jonorsi wrote: post #149
andrewingram wrote: post #146

Earlier quoted context omitted.

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.

styled-components can do automatic injection of critical CSS into the page HTML, but doesn't do static extraction of stylesheets.

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

#152

Post by mekkkkkk »

Kiro wrote: post #134
mekkkkkk wrote: post #77

Earlier quoted context omitted.

I've worked on and off with React since its inception, and the main reason I would use it is simple ergonomics. If you are working with an MVP or a small widget project, you gain a lot of velocity. You don't need to worry about scoping, naming collisions, class toggles, etc. and as long as you use decently small components, it all fits snuggly in the same file as the component definition. The price you pay comes in t…

I've found it easier to maintain CSS-in-JS since I know exactly what will be affected when I change it. I'm always scared to touch the .css files on large projects. I haven't used SCSS modules though.

With my preferred SCSS module setup you get a hybrid solution with the best of both worlds. You can keep a clean stylesheet next to your component and then just:

    import { mainGraphic } from './component.scss';

    [...]

    return (
        
    );
Where `mainGraphic` is a regular class block in the SCSS. So it's pretty straight forward and the mapping is still fairly tight. At bundle time, the class name is minimized, deduped and a hash is added to it that corresponds to the rule content. The generated standalone CSS file also gets hashed for cache busting purposes. It's pretty neat.

And since it's SCSS you can keep constants, mixins, functions, etc. imported and organized within and between SCSS files, separated from the components.

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

#153

Post by betageek »

lwhi wrote: post #141
masswerk wrote: post #109

Earlier quoted context omitted.

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.

CSS-in-JS alone doesn't give you many tools for that kind of stuff, but if you use something that integrates more design system-style theming it's pretty easy - have a look at https://chakra-ui.com/ and click on the moon icon in the top corner for instant dark mode. Implementing various themes for high-contrast etc. would just be a case of changing the theme.

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

#154

Post by earthboundkid »

earthboundkid wrote: post #125
throw_m239339 wrote: post #119

Earlier quoted context omitted.

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.

Web components are a great brand for a collection of mostly awful APIs. Shadow DOM in particular should have just been a CSS property from the start. Glad to see someone starting to recognize this.

Never-mind, read the link. It's just shoveling more crap on top of the existing shadow DOM instead of finally just cutting bait and making a CSS property called `inherit: reset;` like they should have done to begin with.

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

#155

Post by runarberg »

johnnypangs wrote: post #135
runarberg wrote: post #120

Earlier quoted context omitted.

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.

Can anyone give some references on that Web Components have bad dev ergonomics? Is it just that Web Components don't allow passing of complex types so you have to stringify everything?

I see many people have problem with that in the comments here. However I don’t find that to be an issue. Passing properties (as opposed to attributes) allows complex types and many popular frameworks have a handy shorthand for it (e.g. in lit-html you write ``).

In my opinion the bad ergonomics is actually when authoring the components (not consuming it). Many of the faults have been excellently pointed out previously[1]. The most glaring the boilerplate you have to write if you want your attributes to reflect a property.

This has an easy fix though, which is that you simply don’t write your web components by hand. You either use a library (like lit-element[2]) or a compiler (like stencil[3]). I’m personally waiting for a less opinionated compiler with a smaller runtime then stencil (preferably no runtime; perhaps that is Svelte with a web component target, I haven’t tried it).

There is also a proposal for a declarative shadow DOM[4], which aims to tackle some of the bad dev experience we have with web components. However I’m personally a little skeptic that it is a good proposal, or that it will fix what most web component devs are concerned about.

1: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

2: https://github.com/lit/lit-element

3: https://stenciljs.com/

4: https://github.com/whatwg/dom/issues/831

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

#156

Post by jfengel »

lwhi wrote: post #140
Supermancho wrote: post #108

Earlier quoted context omitted.

HN randomly mods posts. Don't assume malice.

Could you please explain what you mean?

I think you should assume malice... but reconcile yourself to the fact that there's not much you can do about it. People engage in petty acts of malice on social media because they can get away with it.

The best you can hope for is to forget about it. It's unsatisfying, but less unsatisfying than trying to get back at them or apply "sour grapes" or whatever. None of that works.

The sooner you put your brain on something else, the sooner you'll forget that somebody was a dick to you and got away with it. It sucks, but it's the least worst alternative. Treat it as noise -- which I think is what the OP was trying to say.

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

#157

Post by iaml »

lwhi wrote: post #138
Aeolun wrote: post #104

Earlier quoted context omitted.

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.

Sure CSS isn't a programming language. However, when used correctly you can create a system that will allow you maintain and apply your presentation layer in an efficient, extensible, consistent and reusable way. Lack of knowledge isn't an excuse for believing otherwise. -- Edit: I'm actually shocked by how much bad feeling there is for standard front-end technology. A domain specific solution is a benefit.

> you can create a system that will allow you maintain and apply your presentation layer in an efficient, extensible, consistent and reusable way.

If that is your intention, typescript is a better tool for the job: you get type safety, ide autocomplete, tests (have you ever written a test for css?). You are right, being a domain specific solution is a benefit, but that has nothing to do with how good of a system you can make with it. I'm sure it's possible to write a system in typescript that would be as good as what you describe, but it will be more flexible at expense of being slower.

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

#158

Post by lenkite »

throw_m239339 wrote: post #119
lstamour wrote: post #50

Earlier quoted context omitted.

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

Please give me web-components without Javascript and I'll start using them heavily.

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

#159

Post by lwhi »

jfengel wrote: post #156
lwhi wrote: post #140

Earlier quoted context omitted.

Could you please explain what you mean?

I think you should assume malice... but reconcile yourself to the fact that there's not much you can do about it. People engage in petty acts of malice on social media because they can get away with it. The best you can hope for is to forget about it. It's unsatisfying, but less unsatisfying than trying to get back at them or apply "sour grapes" or whatever. None of that works. The sooner you put your brain on someth…

I agree re. the assumption; and also the resolution.

I also think it's worth calling it out too though.

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

#160

Post by Supermancho »

lwhi wrote: post #140
Supermancho wrote: post #108

Earlier quoted context omitted.

HN randomly mods posts. Don't assume malice.

Could you please explain what you mean?

New posts get down modded randomly for whatever reason (iirc it was to disrupt some bot karma farming). Wait a day and the post will almost always be back to to the default (1) + any user mods.
Post reply on HN