Ok. So it is basically that going full-on "CSS dictates HTML" approach, which only makes (some) sense if you have full-control of every aspect of the stack and you just want to have a single repository for your design system.

Honestly, the only possible place where this may make sense to me is if you have tooling that can keep a two-say sync between designer tools and programmers tools. I think AirBnB was doing something like that with Sketch?

Aside from that, honestly I am still failing to see any benefit. If you are tying yourself to a JS codebase, you can still do that whole "utility classes at the component level" with plain SASS and global variables and mixins and you still don't need to put class definitions in your HTML.

Let me see if I can draft a quick Vue example:

   <template>
     <button><slot></slot></button>
   </template>

   <script>
     export default {
       name: "my-button"
    }
   </script>

   <style lang="scss">
   @use "my/sass/variables"
   @use "my/sass/mixins/buttons"

   button {
     @include buttons.rounded($variables.radius-button-small)
     @include buttons.colors($active: $variables.primary, $background: $variables.primary-accent, $disabled: $variables.disabled)
   }
   </style>

No Tailwind required. Easy to customize. One central place to organize your style and - most importantly to me - no css classes shoved in the HTML!

Now, someone might ask for "a large button inside the hero section from the home page." Let's go about that...

  <template>
  <div class="hero">
    <p>Welcome to the beautiful site</p>
    <MyButton>Sign up now!</MyButton>
  </div>
  </template>

  <script>
  import MyButton from './my-button.js'

  export default {
    name: "hero",
    components: {MyButton}
  }
  </script>

  <style scoped lang="scss">
  @use "my/sass/variables"

  div.hero {
    button {
      width: $variables.size-button-large-width;
      height: $variables.size-button-large-height;
    }
  }
  </style>

Really, I am yet to understand what I am missing by taking this approach. The example above is contrived, but I don't see why more complex widgets and even whole pages couldn't be done this way. The mixins are the place where you can have all of the abstraction you want, you can even add some logic depending on the values from the variables.

So, let's take a look at the benefits:

- If next week the frontend team decides to switch from Vue to anything else, the SASS code does not need to be touched at all.

- If next week the design team brings a whole new "Design Language", the JS code does not need to be touched at all (unless of course the design system also brings new functionality)

- The styling could even be verified on a series of static HTML pages. If the designer does not do any code, they can verify if the implementation matches the designs by opening a reference template, no need to run a whole JS app.

Downsides:

- If you want the code to be truly portable, your SASS need to follow a standard convention of @mixin names/parameters as well as variables. Honestly though this IS what I would expect from a "CSS framework", so I am not even sure it's a bad thing.

- You don't get to put any hip CSS-in-JS framework on your resume.