Hacker News Reader

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.

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.

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.

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.

There is this video about inline styles 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").

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

Why wouldn't the CSS file be deleted? It should be co-located with the widget, so you just delete the entire widget folder.

Yeah, it's really not hard to delete a CSS file. People really are that lazy, but that's on them, not the technology.

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.

Nobody thinks it's hard to delete a file.

It's hard to know when you can delete a rule. Are you positive that all the rules in your component's CSS file only affect that component? Then great, delete the whole file.

What about the individual rules within that file? How do you know whether your app is still rendering any components with the `fancy` modifier anymore? Keep in mind any JS on the page could be be dynamically toggling the `fancy` class, including in very rare circumstances, including from dynamic data that might bring the string "fancy" with it so that you can't just grep your codebase for it. Is it safe to delete the `fancy` rule?

Another problem is that even BEM admits that sometimes nested selectors are necessary. It's right there in the BEM FAQ: "While in general BEM recommends avoiding nested selectors, in this case they are reasonable."

Sometimes you need your button to look a certain way when it's inside a nav menu item.

So what's the solution? Either a nested selector (targeting both the nav item and the button) or a new modifier on your button, like `is-in-nav-item`.

Eventually your app changes and you're not rendering any buttons in nav items anymore. Maybe nav items don't even exist anymore and you at least remembered to delete those. Are you also going to remember all the places in your code you need to track down to delete these obsolete nested selectors/modifiers? Or is there just going to be dead code now?

What if the selector is slightly more general, and you're not sure if it's targeting other things as well? Are you confident that you won't break anything else? CSS selectors are effectively global. Anything could be secretly relying on the styles that a selector applies.

That is the problem. Not deleting a file. Your individual component CSS files are now the "append-only" stylesheets, not necessarily the whole combined stylesheet.

> Are you positive that all the rules in your component's CSS file only affect that component?

Absolutely

This is where something like CSS Modules comes into its own. You can have (nearly) absolute confidence that what's in the CSS file colocated with the component is only used by that component. Sure, there are escape hatches like `:global(...)`, but those should be considered a code smell.

The beauty of CSS modules over a convention-based approach like BEM is that you end up with cleaner, simpler CSS files -- with selectors like `.Widget .search.error` rather than `.Widget__search--error`. The downside is that there's a compilation step, but chances are that you already have _some_ sort of compilation going on -- even if just to bundle things up.

The way to handle "special" cases for buttons -- like when they appear in certain contexts -- is to allow the calling code to add a class to the button; a class which comes from the caller's own CSS module. Alternatively, use CSS variables:

Button.css

  .Button {
    background: var(--btn-background, turquoise);
    color: var(--btn-foreground, octarine);
  }

Nav.css

  .Nav {
    --btn-background: fuchsia;
    --btn-foreground: lime;
  }

You would like Vue's Single File Components, where HTML, JS, and CSS are all in one file. It's great.

In case anyone else was wondering what BEM is:

http://getbem.com/

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?

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.

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

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.

The underlying technology is the same, only the interface has been changed out(CSS files for JS).

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

That's an interesting use case for IDs. I'll have to keep that in mind.