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
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 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 @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
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
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