Twitter | Search | |
Snook Dec 13
I used SMACSS in a long living large web application with multiple web developers working simultaneously with changing requirements without CSS-in-JS. You know how? By treating CSS the same way JS is treated.
Reply Retweet Like
Snook Dec 13
Replying to @snookca
I don't understand how JS devs can be so good at remembering to use the proper capitalization and making sure they spell variable and property names correctly but throw a .css extension on the file and all hell breaks loose. I don't get it.
Reply Retweet Like
Snook
In what way is JS any more maintainable than CSS? How does writing CSS in JS make it any more maintainable?
Reply Retweet Like More
Jesse J. Anderson Dec 13
Replying to @snookca
Reply Retweet Like
Micah Godbolt Dec 13
Replying to @snookca
For us it's the ability to evaluate styles at runtime. This means that we can move all theming into the top of the application, and everything picks it up via context. This opens up a TON of cross application/cross theme scenarios that static css just won't support.
Reply Retweet Like
Zach Leatherman (Away from ⌨️) Dec 13
Replying to @snookca
oh no I’ve said baggage three times in one tweet
Reply Retweet Like
Noah Stokes Dec 13
Replying to @snookca
I think it’s because CSS is so loose in terms of what you name your ID’s and classes?
Reply Retweet Like
Snook Dec 13
Replying to @jessejanderson
I can do that with CSS or Sass.
Reply Retweet Like
Snook Dec 13
Replying to @micahgodbolt
I'd be curious to see this implemented.
Reply Retweet Like
Snook Dec 13
Replying to @zachleat
Only the first bag is free. Extra baggage is $75.
Reply Retweet Like
Jesse J. Anderson Dec 13
Replying to @snookca
If, on the JS side of things, you are building with components (e.g. using React), it is FAR easier to style those components with CSS in JS than to try to manage composition through separate css files and worry about inheritance, naming conflicts, etc.
Reply Retweet Like
Snook Dec 13
Replying to @motherfuton
I can name my javascript variables and objects whatever I want. I can modify and override prototypes.
Reply Retweet Like
Jesse J. Anderson Dec 13
Replying to @snookca
Naming things is hard—especially when you have to worry about potential conflicts. When using css-in-js, names don't really matter any more because they are isolated within that component. Name conflicts and accidental inheritance goes away completely. I've found it very freeing.
Reply Retweet Like
Snook Dec 13
Replying to @jessejanderson
I build my CSS using components. And thus I have a 1:1 relation between JS components and CSS component. Thus, exactly the same naming conflicts I'd have in JS that I'd have in CSS. For composition, I'd use mixins but usually variables are sufficient.
Reply Retweet Like
Snook Dec 13
Replying to @jessejanderson
I have the same naming issues in CSS that I do in JS. They don't seem any harder or easier.
Reply Retweet Like
Jesse J. Anderson Dec 13
Replying to @joshking @snookca
I don’t think using css/sass is bad or wrong or anything, I just feel like I’ve “seen the light” and want others to have that same feeling and discover the awesome benefits of css-in-js. I was extremely against the idea at first, but the more I used it the more I loved it.
Reply Retweet Like
Sunil Pai Dec 13
Replying to @snookca
Hi, I wrote a reply to this tweet I’m a gist. It got a bit long, but I hope it answers your question, even if partially so 🍻
Reply Retweet Like
Snook Dec 13
Replying to @threepointone
and I managed to finish writing my retort! Thanks!
Reply Retweet Like
Snook Dec 13
I’ve yet to work on a project where any of these tools feel like they are improving things. I don’t feel like it helps me code any faster or creates more optimized code for production.
Reply Retweet Like