4 ms·

Maybe it's just my experience, but I've never understood introducing the mental overhead of something like styled components. Why don't you just have one compon

by MsMowz 9y ago

Maybe it's just my experience, but I've never understood introducing the mental overhead of something like styled components. Why don't you just have one component per JS file and a stylesheet with the same name as the component in the same directory? That's quickly becoming the standard, at least in the circles I run in, and the reason is because it's (1) super easy to configure and (2) requires zero mental overhead. Also worth noting that none of the five advantages listed are exclusive to Styled Components, but every one of its disadvantages is.

SirHound 9y ago
> the mental overhead of something like styled components I've outlined a number of ways in which it reduces mental overhead, for instance removing SASS-specific syntax, reusing existing JS code, throwing errors for missing styles. > Why don't you just have one component per JS file and a stylesheet with the same name as the component in the same directory? Code this atomic is quickly a mess. > (1) super easy to configure This is not true if you wish to gain many of the benefits I've outlined. > none of the five advantages listed are exclusive to Styled Components, but every one of its disadvantages is. Six and the presence of all six within one solution is something I haven't encountered elsewhere (not to say it doesn't exist). Also to say every disadvantage is exclusive to SC is simply untrue.
- MsMowz 9y ago
  I wasn't considering semantic tags to be a feature, since that's kind of trivial, but I guess I should've. I just can't help but feel you're really overcomplicating something that doesn't have to be a problem. Styling is probably the hardest thing to get wrong in a modern web application. >removing SASS-specific syntax, reusing existing JS code, throwing errors for missing styles. Throwing errors for missing styles is a nice bonus, but nobody is making you use a preprocessor, especially if you use atomic stylesheets, and you've avoided reusing existing code by introducing way more new code. That's not the point of DRY.

by MsMowz 9y ago

SirHound 9y ago

> the mental overhead of something like styled components I've outlined a number of ways in which it reduces mental overhead, for instance removing SASS-specific syntax, reusing existing JS code, throwing errors for missing styles. > Why don't you just have one component per JS file and a stylesheet with the same name as the component in the same directory? Code this atomic is quickly a mess. > (1) super easy to configure This is not true if you wish to gain many of the benefits I've outlined. > none of the five advantages listed are exclusive to Styled Components, but every one of its disadvantages is. Six and the presence of all six within one solution is something I haven't encountered elsewhere (not to say it doesn't exist). Also to say every disadvantage is exclusive to SC is simply untrue.

MsMowz 9y ago
I wasn't considering semantic tags to be a feature, since that's kind of trivial, but I guess I should've. I just can't help but feel you're really overcomplicating something that doesn't have to be a problem. Styling is probably the hardest thing to get wrong in a modern web application. >removing SASS-specific syntax, reusing existing JS code, throwing errors for missing styles. Throwing errors for missing styles is a nice bonus, but nobody is making you use a preprocessor, especially if you use atomic stylesheets, and you've avoided reusing existing code by introducing way more new code. That's not the point of DRY.