I personally never ever ran into any problem, when I myself named CSS classes and that is because I automatically think about the future and whether a name could conflict with something else, instead of being lazy and typing 3 characters and thinking I did my job. I am simply careful and use prefixes and give unique names, so that it has such a low chance of someone else using that CSS class name, that it simply never happened in practice. So from my personal experience all that mumbo-jumbo about CSS name collisions comes from people not being careful and is a "house made" problem, not a problem of CSS. I never had any need to use JS to do what is CSS's job.

Using JS for doing something CSS should do is furthermore dangerous, since clever people deactivate their JS or block it partially. For me personally, your (not you personally, but you in general, anyone who reads this) JS better comes from your own domain, or it will be blocked by default. If you can live with people seeing your website utterly destroyed by its inability to apply style, then OK, do the styling in JS.

Angular implements a polyfill for this. Every angular component has 3 files html, ts, (s)css, and the styles in the components css file are automatically scoped to just the component they apply to. It takes away all the stress of global css selectors, and if you want to share styles you can just have a library of shared styles and import them via scss. It's honestly heavenly and I haven't thought about conflicting selectors in years.

Very typically, for a given app and page the styles of individual elements and components are not independent. They also depend the app theme, app section, layout area, component group, etc. The element fits the component. The component fits into the section, the section fits into the page. The specific relationships in a particular case are different of course. Styles are visual and the idea that a component on a page has nothing visually to do with the rest of the page is wrong.

The typical scoping rules of programming languages doesn't fit that well here.

To the extent some styling solution encourages you to treat styles that are dependent as independent, that's not a good or useful thing.

Does the annoyance primarily center around the fact that styles cascade to child elements? Hard to tell from the article.

It has different functionalities.

  <StackPanel>
    <StackPanel.Resources>
      <Style TargetType="TextBlock">
        <Setter Property="Foreground" Value="Red" />
      </Style>
    </StackPanel.Resources>

    <TextBlock Text="Red" />

    <StackPanel>
      <StackPanel.Resources>
        <Style TargetType="TextBlock">
          <Setter Property="Foreground" Value="Green" />
        </Style>
      </StackPanel.Resources>

      <TextBlock Text="Green because the default style was reset by the nested container" />

    </StackPanel>

    <TextBlock Text="Red again because the nested container scope has ended" />

  </StackPanel>

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

  <header className="default-header" style={theme && theme.header}>
  <button className="default-button" style={theme && theme.button}>

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.

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.

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

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.

http://getbem.com/

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?

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.

Why don't we have more : "We tried it, it is the worst, especially for products which lifespan is more than two months"

But as you pointed out, there is no cascade and no sheet. The styles apparently just apply to the stuff they are near in the code. No twisted logic to unwind, hence no spaghetti.

The potential problem I could see is that changes which would have been easy with a cascade would require lots of changes to copypasta in this approach. Like, "take the spinach out of this ravioli and replace it with mushrooms." Everything is scoped properly and the task is obvious at a glance-- it's just annoying.

https://vue-loader.vuejs.org/guide/scoped-css.html#scoped-cs...

Inspect the result here: https://codesandbox.io/s/3v0pjzoy7q

Where is template getting assigned to the code inside the script tag?

Does OtherComponent somehow mysteriously map to other-component? How does one pass arguments to it? Is a .vue file actually HTML or is it parsed somehow to be HTML?

The thing I like about React is the explicitness of it. This is a source code file that exports component X. Component X uses style Y as defined above because it's explicitly passed in as a prop, etc etc.

What language are you talking about? React is Javascript

> Look at this beauty for comparison

Meanwhile Vue is neither HTML [1], nor strictly speaking CSS [1], and has a very wierd concept of how objects work in JS.

[1] It's a templating system with its own rules and mini-DSLs that ends up being compiled into JS.

Add in Tailwind utility classes and you've got a great design system that can be built on the fly with consistent standards.

I think there’s truth to your second point though - reusing styles in parts of a project that does not use the same framework. Something like Tailwind CSS can be a good option then.

I guess the concern for longevity most devs have is amusing when most software, if its not like systems level stuff, or problems most devs dont want to solve, tends to get disposed pretty frequently.

By the way, most of the software that actually sticks around was written in C and generally solves a problem most people wont tackle. Like zlib or sqlite or nginx or the linux kernel. You can almost pretty much judge the longevity of a piece of software based on how hard the problem it tackles is. Like encryption or compression? Those libraries are going to be around forever, because how many coders do you know that can write a semi compitent encryption library? And how manu coders can write a templating engine?

Like most of web dev is throwaway code. It just is. Arguments based on like "will they be able to restyle it in 10 years?" Well are they even going to be around?

Better to have a cohesive set of theme/rules and get them to work together as best possible. I've been a big fan of material-ui and react-jss and is imho about the best option I've used in over two decades of working on web based applications.

So just put the styles in separate .js files and import them.

People not taking the time to learn is not a reason to throw an entire building block of the web out.

(Yes, I realize there are a lot of people who know CSS and still choose CSS-in-JS, but I'm specifically referencing the point re: not learning CSS.)