40 ms·

I understand the "pit of success" idea, particularly when it comes to more junior devs. But I don't necessarily agree that you need stringent processes to get m

I understand the "pit of success" idea, particularly when it comes to more junior devs. But I don't necessarily agree that you need stringent processes to get most of the gains you cite from using something like SCSS or even regular CSS these days. It's really easier than ever. 1- append only? No, each module/feature/widget gets its own CSS file, imported to the main app CSS file. Delete the widget? Delete the file. 2- Specificity issues? Never use IDs, stop using tag names and simple classes and adopt a simple naming structure (doesn't have to be BEM, it could literally be ".widgetName-header") Since I adopted those 2, I've almost never had dead CSS from deleting features or collisions in my CSS. I do still have a small base set of styles that are shared but it's small enough to be easily manageable. 3- dynamic properties? CSS variables. Not an option? Child classes that apply the dynamic styles serve most use cases. Truly dynamic styles are rare, in my experience. I'm still keeping an open mind about the possibilities, but my strong opinion (weakly held) is that I still don't see CSS-in-JS as more of a bandaid for people that like CSS and (for many, not all) those that don't have an in-depth understanding of it.

arethuza 8y ago
In case anyone else was wondering what BEM is: http://getbem.com/ http://getbem.com/
ggregoire 8y ago
That's also what we do here on a dozen of apps and it works. Each component has its own folder with its own css file and each rule starts with .name-of-the-component. For dynamic properties, we either create conditional classes (e.g. 'success', 'error') or pass the rules through 'style' (e.g. dynamic height). For dynamic themes, we create an object at the root of the app const theme = { header: { backgroundColor: black }, button: { backgroundColor: black }, ... } Then pass it down to the related components <header className="default-header" style={theme && theme.header}> <button className="default-button" style={theme && theme.button}> That being said, I tried styled-components once and don't really have negatives about it. It's a viable option.
qudat 8y ago
> Delete the widget? Delete the file. This rarely happens. I would argue that creating an automated system to enforce "rules" should be favored over forcing every developer to know the rules and abides by them. It is much easier to understand the relationship between css and js when the css is just a js variable. Having built many large applications using the CSS file method, css modules, each widget gets its own file, co-locating css files with the js, I much prefer using `styled-components`. It provides a ton of flexibility, it opens doors for dynamic css by leveraging js (the hacks I've seen, had to write to get css dynamic is astounding), and I don't have to look very far to see how it's being used because the CSS is literally attached to the component I'm using. All I do in VSCode is cmd+click and bam, I can see the CSS for this component. There's no need for naming convention, there's no worry about global css variables getting into your styles, and there's no digging around looking for css that might be influencing your component. The best part for me is: when I delete the component, the CSS is gone as well. There's no thought put into scouring the FS to find lingering CSS that used to be used. I love `styled-components` and most of the designers I work with also enjoy it.
- LocalPCGuy 8y ago
  Why wouldn't the CSS file be deleted? It should be co-located with the widget, so you just delete the entire widget folder.
  - ravenstine 8y ago
    Yeah, it's really not hard to delete a CSS file. People really are that lazy, but that's on them, not the technology.
    - BurningFrog 8y ago
      This is a losing argument. Judge all you want, but you can only change technology, not human nature. Good engineering is to find pragmatic solutions that work in the real world.
    - exogen 8y ago
ravenstine 8y ago
> 2- Specificity issues? Never use IDs, stop using tag names and simple classes and adopt a simple naming structure I have one exception to that in my own work, which is to only ever use IDs for styles that affect the layout of a block/component on a specific page. This makes sense since parts of a page layout are usually very specific and not that dynamic(in which case class names might be more appropriate). At the same time, component-level styles should never make assumptions about how they are positioned on a given page. Let's say that we have a page `/blog/:entry_id`, and this page has a right-hand column to list related blog entries. This component would have an id `#blog-entry__entries-list`, which would control how the related-entries list appears on the blog-entry page(in this case, putting it in a column on the right), and a `.entries-list` class that controls the global appearance of the component. This way, the entries-list can be used in different contexts without having weirdness caused by a margin working fine on one page but having to be negated on another page where the margin doesn't work. Try to add styles, but do as minimal overriding as possible. In combination with BEM, primarily for the benefit of all selectors having the same specificity, I've found this separation of concerns between IDs and class names to be very powerful and simple to understand, especially since it doesn't require more verbosity. Another part of my styling workflow is Sass mixins. Let's say that we want the entries-list component to appear more compact on another page. Perhaps it appears somewhere on the site index, and takes up a little more room than we'd like. Since component styles can't assume anything about their environment, and since layout styles(i.e. our ID selectors) can't know about the inner workings of their components, there needs to be a way for layouts to have a choice of component variations. In this case, I would create a mixin `entries-list--compact` inside the entries-list Sass file, which would contain CSS properties that would make the entries-list smaller. Back on in the index Sass file, I would include that mixin: ``` #index__entries-list { @include entries-list--compact; } ``` But what if we only need the list to be compact at a specific page width? ``` @media (max-width: 640px){ #index__entries-list { @include entries-list--compact; } } ``` I've found this pattern of mixins to be very powerful. Any page can decide whether to use any mixin at any page-width. CSS for layout stays very lean, as the only properties it's concerned with 99% of the time is width, height, margin, and padding. A component can be completely replaced with new styles and behave properly on existing pages so long as it conforms to its existing "API" of mixins.
realharo 8y ago
There is this video about inline styles https://www.youtube.com/watch?v=k3OF4A30jSQ https://www.youtube.com/watch?v=k3OF4A30jSQ, based on a lot of real-world experience. It addresses some of these points at 35:23 - that you can kind of make CSS work if you always do everything right, but it's not as easy in practice (most of the experience stuff is at the beginning - which shows that they did kinda do everything "right").
dmitriid 8y ago
> using something like SCSS > adopt a simple naming structure and suddenly > I still don't see CSS-in-JS as more of a bandaid for people that like CSS Why are SCSS or poor-man's-substitute-for-modularity in the form of naming conventions fine, and why JS-in-CSS is bad?
- LocalPCGuy 8y ago
  Because one is an extension of the underlying technology, and the other one changes the technology out altogether. I still believe CSS is a vital part of the web ecosystem, and we should work to fix the underlying issues rather than just try to work around it via JS.
  - Rapzid 8y ago
    The underlying technology is the same, only the interface has been changed out(CSS files for JS).
- deleted 8y ago
  [deleted]
jypepin 8y ago
I agree with you. I've done both approaches at scaled, and I'm still not really sold on CSS-IN-JS. Of course, I think it's a matter a taste (and maybe experience?) so to each its own. Personally I much prefer using separate css (or sass) file, one for each component (assuming you also have a "layout" component for shared styles) and import each relevant css file as a module. This way you keep writing our CSS out of your JS, but still can keep it scoped to your component. It's also obvious what css a component uses, and each to grep for when you want to delete some css.
jimmaswell 8y ago
How is it better to have only one of something and give it a class that nothing else uses than to use IDs how they're intended?
- LocalPCGuy 8y ago
  I take issue with your assertion about how IDs "are intended". I think that idea (and CSS being taught that way) is one of the reasons people have trouble with CSS. There are quite a few reasons for preferring to not use IDs, here's two: 1- specificity of IDs always trumping things 2- having to change it from an ID to a class later on if it becomes a reusable item (which in a widget, is almost always the case). There is no reason a class cannot apply to just a single item, where an ID is by its nature limited.
fro0116 8y ago
All three of the points raised are just dismissing the root of the problem and offering a "solution" using plain CSS classes that relies on everybody following some bespoke convention to work around the problem rather than addressing it head-on like CSS-in-JS solutions do. 1. and 2. attempt to address the lack of modularity in CSS through convention when you can have guaranteed modularity through auto-generated CSS classes that are content-addressed and thereby globally unique by definition with CSS-in-JS. Not to mention you can use a real module system for sharing styles instead of being limited to sharing variables through some global context, which again opens up the possibility of name clashes. 3. recommends a solution for dynamic styles based on yet another CSS feature that relies on global namespacing, and then a fallback based on string concatenation that can't actually address all dynamic use cases. Then it goes on to dismiss the use case entirely, when in a single page application, all styles are inherently dynamic based on the state of the components that are currently being rendered, which is why there's such a painfully obvious impedance mismatch when implementing anything that's truly dynamic using CSS classes, when you have to resort again to concatenating lists of static classes together rather than mapping state to styles directly like you could with CSS-in-JS. Of course, I'm not saying those approaches can't work at all, nobody is saying that. You can obviously make them work, and people have used those approaches for ages before CSS-in-JS came along. But using the existence of those approaches to dismiss a different approach that tangibly addresses the inherent flaws of those approaches doesn't feel like a particularly compelling argument.
- LocalPCGuy 8y ago
  Yes, it's dismissing the root of the problem because I am not convinced the "cost of doing CSS" is enough to justify moving to something like CSS-in-JS. Again, as I said above - it's a strong opinion, but weakly held - given enough evidence, I'd reconsider my position. My point with the examples I gave was just to show that it's possible to handle the issues the author wrote about. I'd prefer to see efforts to fix the issues in CSS instead of discarding it completely in favor of a JS solution. I'm not saying I can specify how to "solve" CSS issue in a couple paragraphs. As regards #3, that's specific to the kinds of dynamic styles I find most often in web apps. Very rarely do I see styles generated dynamically where it isn't effectively a choice between a couple of options (in my experience, of course). And when you do, you can just write out styles from the JS into the template (and I've definitely done fully dynamic styles in that way when it is necessary). Dynamic styles would be a place where I could see a fit for CSS-in-JS, btw. The global namespacing this is something I believe is being worked on in the CSS Modules specification, but again, that is really easily solved. I can say loading external libraries can mess that up (i.e. Bootstrap and the ilk). I don't care what people use, I'm glad the argument is what the author (who co-wrote the styled components lib) was what he liked. But I am really concerned that some proponents promote their way as the only way forward. Personally, I haven't found a situation yet where CSS-in-JS would materially benefit the application over a careful, convention-based approach. And I want to make sure people know there are other options that work.

arethuza 8y ago

In case anyone else was wondering what BEM is: http://getbem.com/ http://getbem.com/

ggregoire 8y ago

That's also what we do here on a dozen of apps and it works. Each component has its own folder with its own css file and each rule starts with .name-of-the-component. For dynamic properties, we either create conditional classes (e.g. 'success', 'error') or pass the rules through 'style' (e.g. dynamic height). For dynamic themes, we create an object at the root of the app const theme = { header: { backgroundColor: black }, button: { backgroundColor: black }, ... } Then pass it down to the related components <header className="default-header" style={theme && theme.header}> <button className="default-button" style={theme && theme.button}> That being said, I tried styled-components once and don't really have negatives about it. It's a viable option.

qudat 8y ago

> Delete the widget? Delete the file. This rarely happens. I would argue that creating an automated system to enforce "rules" should be favored over forcing every developer to know the rules and abides by them. It is much easier to understand the relationship between css and js when the css is just a js variable. Having built many large applications using the CSS file method, css modules, each widget gets its own file, co-locating css files with the js, I much prefer using `styled-components`. It provides a ton of flexibility, it opens doors for dynamic css by leveraging js (the hacks I've seen, had to write to get css dynamic is astounding), and I don't have to look very far to see how it's being used because the CSS is literally attached to the component I'm using. All I do in VSCode is cmd+click and bam, I can see the CSS for this component. There's no need for naming convention, there's no worry about global css variables getting into your styles, and there's no digging around looking for css that might be influencing your component. The best part for me is: when I delete the component, the CSS is gone as well. There's no thought put into scouring the FS to find lingering CSS that used to be used. I love `styled-components` and most of the designers I work with also enjoy it.

LocalPCGuy 8y ago
Why wouldn't the CSS file be deleted? It should be co-located with the widget, so you just delete the entire widget folder.
- ravenstine 8y ago
  Yeah, it's really not hard to delete a CSS file. People really are that lazy, but that's on them, not the technology.
  - BurningFrog 8y ago
    This is a losing argument. Judge all you want, but you can only change technology, not human nature. Good engineering is to find pragmatic solutions that work in the real world.
  - exogen 8y ago

ravenstine 8y ago

> 2- Specificity issues? Never use IDs, stop using tag names and simple classes and adopt a simple naming structure I have one exception to that in my own work, which is to only ever use IDs for styles that affect the layout of a block/component on a specific page. This makes sense since parts of a page layout are usually very specific and not that dynamic(in which case class names might be more appropriate). At the same time, component-level styles should never make assumptions about how they are positioned on a given page. Let's say that we have a page `/blog/:entry_id`, and this page has a right-hand column to list related blog entries. This component would have an id `#blog-entry__entries-list`, which would control how the related-entries list appears on the blog-entry page(in this case, putting it in a column on the right), and a `.entries-list` class that controls the global appearance of the component. This way, the entries-list can be used in different contexts without having weirdness caused by a margin working fine on one page but having to be negated on another page where the margin doesn't work. Try to add styles, but do as minimal overriding as possible. In combination with BEM, primarily for the benefit of all selectors having the same specificity, I've found this separation of concerns between IDs and class names to be very powerful and simple to understand, especially since it doesn't require more verbosity. Another part of my styling workflow is Sass mixins. Let's say that we want the entries-list component to appear more compact on another page. Perhaps it appears somewhere on the site index, and takes up a little more room than we'd like. Since component styles can't assume anything about their environment, and since layout styles(i.e. our ID selectors) can't know about the inner workings of their components, there needs to be a way for layouts to have a choice of component variations. In this case, I would create a mixin `entries-list--compact` inside the entries-list Sass file, which would contain CSS properties that would make the entries-list smaller. Back on in the index Sass file, I would include that mixin: ``` #index__entries-list { @include entries-list--compact; } ``` But what if we only need the list to be compact at a specific page width? ``` @media (max-width: 640px){ #index__entries-list { @include entries-list--compact; } } ``` I've found this pattern of mixins to be very powerful. Any page can decide whether to use any mixin at any page-width. CSS for layout stays very lean, as the only properties it's concerned with 99% of the time is width, height, margin, and padding. A component can be completely replaced with new styles and behave properly on existing pages so long as it conforms to its existing "API" of mixins.

realharo 8y ago

There is this video about inline styles https://www.youtube.com/watch?v=k3OF4A30jSQ https://www.youtube.com/watch?v=k3OF4A30jSQ, based on a lot of real-world experience. It addresses some of these points at 35:23 - that you can kind of make CSS work if you always do everything right, but it's not as easy in practice (most of the experience stuff is at the beginning - which shows that they did kinda do everything "right").

dmitriid 8y ago

> using something like SCSS > adopt a simple naming structure and suddenly > I still don't see CSS-in-JS as more of a bandaid for people that like CSS Why are SCSS or poor-man's-substitute-for-modularity in the form of naming conventions fine, and why JS-in-CSS is bad?

LocalPCGuy 8y ago
Because one is an extension of the underlying technology, and the other one changes the technology out altogether. I still believe CSS is a vital part of the web ecosystem, and we should work to fix the underlying issues rather than just try to work around it via JS.
- Rapzid 8y ago
  The underlying technology is the same, only the interface has been changed out(CSS files for JS).
deleted 8y ago
[deleted]

jypepin 8y ago

I agree with you. I've done both approaches at scaled, and I'm still not really sold on CSS-IN-JS. Of course, I think it's a matter a taste (and maybe experience?) so to each its own. Personally I much prefer using separate css (or sass) file, one for each component (assuming you also have a "layout" component for shared styles) and import each relevant css file as a module. This way you keep writing our CSS out of your JS, but still can keep it scoped to your component. It's also obvious what css a component uses, and each to grep for when you want to delete some css.

jimmaswell 8y ago

How is it better to have only one of something and give it a class that nothing else uses than to use IDs how they're intended?

LocalPCGuy 8y ago
I take issue with your assertion about how IDs "are intended". I think that idea (and CSS being taught that way) is one of the reasons people have trouble with CSS. There are quite a few reasons for preferring to not use IDs, here's two: 1- specificity of IDs always trumping things 2- having to change it from an ID to a class later on if it becomes a reusable item (which in a widget, is almost always the case). There is no reason a class cannot apply to just a single item, where an ID is by its nature limited.

fro0116 8y ago

All three of the points raised are just dismissing the root of the problem and offering a "solution" using plain CSS classes that relies on everybody following some bespoke convention to work around the problem rather than addressing it head-on like CSS-in-JS solutions do. 1. and 2. attempt to address the lack of modularity in CSS through convention when you can have guaranteed modularity through auto-generated CSS classes that are content-addressed and thereby globally unique by definition with CSS-in-JS. Not to mention you can use a real module system for sharing styles instead of being limited to sharing variables through some global context, which again opens up the possibility of name clashes. 3. recommends a solution for dynamic styles based on yet another CSS feature that relies on global namespacing, and then a fallback based on string concatenation that can't actually address all dynamic use cases. Then it goes on to dismiss the use case entirely, when in a single page application, all styles are inherently dynamic based on the state of the components that are currently being rendered, which is why there's such a painfully obvious impedance mismatch when implementing anything that's truly dynamic using CSS classes, when you have to resort again to concatenating lists of static classes together rather than mapping state to styles directly like you could with CSS-in-JS. Of course, I'm not saying those approaches can't work at all, nobody is saying that. You can obviously make them work, and people have used those approaches for ages before CSS-in-JS came along. But using the existence of those approaches to dismiss a different approach that tangibly addresses the inherent flaws of those approaches doesn't feel like a particularly compelling argument.

LocalPCGuy 8y ago
Yes, it's dismissing the root of the problem because I am not convinced the "cost of doing CSS" is enough to justify moving to something like CSS-in-JS. Again, as I said above - it's a strong opinion, but weakly held - given enough evidence, I'd reconsider my position. My point with the examples I gave was just to show that it's possible to handle the issues the author wrote about. I'd prefer to see efforts to fix the issues in CSS instead of discarding it completely in favor of a JS solution. I'm not saying I can specify how to "solve" CSS issue in a couple paragraphs. As regards #3, that's specific to the kinds of dynamic styles I find most often in web apps. Very rarely do I see styles generated dynamically where it isn't effectively a choice between a couple of options (in my experience, of course). And when you do, you can just write out styles from the JS into the template (and I've definitely done fully dynamic styles in that way when it is necessary). Dynamic styles would be a place where I could see a fit for CSS-in-JS, btw. The global namespacing this is something I believe is being worked on in the CSS Modules specification, but again, that is really easily solved. I can say loading external libraries can mess that up (i.e. Bootstrap and the ilk). I don't care what people use, I'm glad the argument is what the author (who co-wrote the styled components lib) was what he liked. But I am really concerned that some proponents promote their way as the only way forward. Personally, I haven't found a situation yet where CSS-in-JS would materially benefit the application over a careful, convention-based approach. And I want to make sure people know there are other options that work.