The website is being rate limited, here’s a google cached version https://webcache.googleusercontent.com/search?q=cache%3Ahttp...
What is the author doing that a static site is rate limited in cloudflare?
Tailwind haters ;-)
Real-world CSS vs. CSS-in-JS performance comparison
71–80 of 165 posts
Re: Real-world CSS vs. CSS-in-JS performance comparison
#72Can 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'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 modules totally solve this without any css in js
Re: Real-world CSS vs. CSS-in-JS performance comparison
#73A 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…
It depends a lot on the context if that context is React. CSS in JS in retrospect looks like a shim for react developers who couldnt rewrite their code to single-file components like in Vue and later Svelte. You dont have to be a genius to know how to name and structure dom elements, though being good at it lets you reuse css and reduce overall app size better than any bundler ever will - but its just easier to install Tailwind.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#74For others seeing a rate-limit message: https://web.archive.org/web/20210608190243/https://pustelto....
<3
Re: Real-world CSS vs. CSS-in-JS performance comparison
#75Can 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?
If you have a lot of dynamic styles that respond to application state, then even with vanilla CSS you are often writing JS to manage class declarations to get the right CSS combinations. With styled-components, instead of adding/removing/combining class names, you can write javascript inside your declarations that use the state variables. For me, writing javascript that directly sets css properties based on state var…
> 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.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#76Can 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…
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.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#77Can 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'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 the way of performance and maintainability. Since the line becomes very blurry between styling and markup, it's up to the dev(s) to bring order to potential chaos.
For any bigger project, my go to solution is SCSS modules. It's by far the most versatile solution I've tried if you want to roll your own CSS and not rely on a CSS framework. You don't need to worry about scoping, the bundle process is excellent, you have access to all of your normal SCSS shenanigans and most important it's a solution that makes it dead easy to collect or break down parts into logical units.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#78I wrote SnackUI[0] to solve this exact problem. It gives you in my opinion a nicer style syntax (flat style props on the component) while avoiding the downsides of CSS-in-JS by extracting everything but the most dynamic parts to pure CSS. The optimizing compiler part was a large investment to get right, especially with theme and media query support. But the main claim to fame is that it also works on React Native, an…
Why the downvotes?
I noticed this a while ago. Some people with the ability to downvote, downvote some comments for no reason, other than hating the comment somehow. They try to release their hate through the downvote, which is funny actually.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#79Can 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?
If you have a lot of dynamic styles that respond to application state, then even with vanilla CSS you are often writing JS to manage class declarations to get the right CSS combinations. With styled-components, instead of adding/removing/combining class names, you can write javascript inside your declarations that use the state variables. For me, writing javascript that directly sets css properties based on state var…
I’ve had great luck achieving that with CSS custom properties. I assign a custom property to a style rule and then change that property with JavaScript when needed.
I also find much state has a nice selector (e.g. :hover, :checked, :invalid, :empty, :focus-inside, etc.) or media queries `@media (prefers-color-scheme: dark)` which I can change the custom property values inside. So it is really an exception when I manually need to change the value of custom properties with JavaScript.
Re: Real-world CSS vs. CSS-in-JS performance comparison
#80Earlier quoted context omitted.
You can address points 1 and 3 via (s)css modules. But point 2 and 4 stand.
You can also kind of address 4 by using `calc` and custom properties in CSS. (eg: `margin-left: var(--page-margin);`)
We started using CSS in JS a few years ago because we couldn’t, and still are unable to use CSS variables (some of our customers still require IE11 support and we can’t drop it until 2022).
The main issue I still see with CSS variables is IDE support and static validation. With my CSS written in typescript I know that every variable I’ve imported works statically.