41–50 of 165 posts
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?
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?
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?
For example, I've used it on a personal app to allow adjusting the placement and opacity of controls. I prefer the CSS-in-JS approach because the code is simple to understand, I can reuse the code in multiple areas, and I can pass state to some function to generate the styling. I also imagine that I could also write some spec to support it, but it's not something that I plan on quite yet.
It's not a technique that I would use for ALL styling, but I think for the use-case I mentioned above, it works great.
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…
I try to focus on writing nice HTML often multiple relevant class names. Then later make things look the way I want in CSS.
I find it hard to think in CSS in translate that to HTML but a lot of developers I know tend to work that way.
Earlier quoted context omitted.
React doesn't have a CSS prop.
Must be referring to the style prop for jsx elements whose argument conforms to the React.CSSProperties interface
The real question is whether we want styling/theming to be in it's own domain specific language. From an ergonomics standpoint, CSS is such a bad language we would rather write JS instead. But the downside of not having it in a more restricted language is that it's much harder to build tooling for it. For example, you won't be able to open up any webpage and know you can inspect and change the style of things. Instead you need to know the specific JS class for that component or ThemeProvider and modify that instead. Every ui framework is going to do things slightly differently which will be a huge blow to user customizability.
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…
I've really enjoyed tailwind after using styled for a while. At least for my applications, the computers my users run on can't handle the performance implications of styled. But beyond the performance, I legitimately build faster using tailwind. I also find it easier to understand the components others build as well.
It was a little struggle at first with our previous setup, but I spent a week or so moving everything over to Vite with hot module replacement which has been life changing.
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.
(eg: `margin-left: var(--page-margin);`)
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…
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-scoped
If we get this the only thing I'll continue to dislike about Web Components would be the global namespace of web components and that Web components HTML attributes can't be rich objects or arrays natively. (I'd love it if web browsers simply implemented JSX, for example, or a syntax that looks like DOM but is actually a function call that can produce DOM. Bonus points if they also implement Markdown or MDX as an HTML element of some kind.)