61–70 of 165 posts
I 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…
Earlier quoted context omitted.
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 and Javascript aren't concerns, they're technologies, and separation of technologies isn't a software engineering principle. "Concern" is pretty undefined in general. If anything, they're all part of the "view" concern. It's the same reason why JSX doesn't violate separation of "concerns."
You're being obtuse. JavaScript is used for more than presentation.
Earlier quoted context omitted.
Moving goalposts is not a concern either. CSS and Javascript are concerns, becaus HTML is of content/structure, CSS is for styling and JS is for behaviour. Of course somewhere along the road devs thought that HTML and CSS are to primitive to spend any time learning them properly, because of that they later found them to bee too complex and we ended up in the mess we are right now, when we try to hide the lack of unde…
> CSS is for styling The web has never lived up to that ideal. Sometimes you need to add a wrapper div with no semantics to make your layout work. Sometimes you need some Javascript to do a special layout CSS doesn't support or work around some other limitation. I've never seen a project that actually had meaningful "separation of concerns" based on technology, whereas almost every componentized project has at least…
> I've never seen a project that actually had meaningful "separation of concerns" based on technology.
With respect, you just need to look a little harder.
I've used react libraries which are fundamentally tied to their styling, due to the fact they use CSS in JS.
Applying custom styling has been more difficult than it should have been.
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?
If you want to have a range of applicable values for some CSS property or state-based styling, CSS-in-JS can be a good tool for expressing that as opposed to writing JS that updates some styling declaratively. 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 a…
Earlier quoted context omitted.
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.
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.
Can encourage others to give it a try as well. Dev productivity through the roof indeed :)
Earlier quoted context omitted.
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.
I don't see CSS-in-JS as a rejection of separation of concerns. In fact, one of the big advantages of CSS-in-JS is that it lets you decide how best to separate your concerns. Using hand-tuned CSS will undoubtedly be the most performant option, but it leaves you with very difficult problems at the boundary of your styling and content/structure concerns. If you have even a sliver of dynamic content in your website, it…
If you want to share styling between your app and your website; I would also state that this process is made more difficult.
If you want to create, implement and maintain an atomic design system to build in consistency and reuse .. again, more complicated that it might have been.
To add to that, this article suggests that there's a performance deficit.
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 of `css={Css.m4.black.$}` in our app need to change.
Basically we're using our Truss DSL both for atomic/utility class names today + a decoupling layer to switch CSS-in-JS libs in the future if/when needed.
I think Linaria and https://github.com/twstyled/twstyled (based on/forked from Linaria) are the closest to doing this eval during compilation, but haven't had to dig in so far (runtime emotion has been fast enough for us so far).
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 love not having to come up with class names. That's it.
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?
If you want to have a range of applicable values for some CSS property or state-based styling, CSS-in-JS can be a good tool for expressing that as opposed to writing JS that updates some styling declaratively. 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 a…
For making code easier to understand you can set a CSS custom property instead of specific style values, and the CSS will be really straight forward.
> You cannot access this site because the owner has reached their plan limits. Check back later once traffic has gone down. First time I've seen this Cloudflare error. Doesn't their free plan have almost ~1TB buffer before they take notice and ask you to upgrade?
https://developers.cloudflare.com/workers/platform/limits#wo...