Unique identifiers are something that should be added separately.

It's not just debugging: If you're doing any kind of testing on the UI you already need class or data attributes to identify the components you're using, otherwise you test becomes coupled to the structure, or worse: to the styling.

The difference of Tailwind to other methodologies is that the Tailwind classes are used exclusively for layout.

I actually went through a phase after realising this of outputing strings of utility classes to named variables to essentially emultate the benfits of CSS class names. My next realisation was that I might as well just be writing plain CSS. In the end I recognised that the things I actually liked about functional CSS were more or less the same things I liked about CSS-in-JS: colocating styles and markup (albeit with blocks of css rather than utility classes) and the approximate scoping of styles. I ended up writing a build tool that fascilitates this outside of React / JS.

This is a problem that should be solved by the framework. With React you can look at the virtual tree instead of html.

If you're using a frontend framework, sure, you can use React devtools or equivalents.

I think tailwind in React does make a lot of sense, but I think there are even more simple solutions to use inside React that solve the same problems but with normal CSS and none of the extra tooling and config of Tailwind.

You can think of tailwind like a higher level language for CSS, since you are writing inline CSS again just with more concise attributes. With that being it's only real advantage in my opinion, I didn't think it was worth learning a whole new dialect just to avoid a few lines of CSS. CSS variables can be solved trivially with an imported JS object, so the config file as well adds a lot of minutiae knowledge without delivering that much more benefit.

At any rate, it is for some people and not others. I'm not going to try too hard to objectively prove why I don't like it, it just adds a lot of tooling overhead while not really solving enough problems for me.

Exactly. Every time you find yourself doing copy paste for a whole range of elements, introduce a component with its own collection of style classes.

Yes, that would work well if you are using a frontend JS framework.

You can achieve the same thing with SSR frameworks as well. e.g.

```

  {{ recent_blog_posts(blogPosts) }}

```

can be a function that expands to:

```

  <aside class="border-pink border-1 rounded bg-orange">

    {% for post in blogPosts %}  

      <li class="text-underline text-purple font-list">...</li>  

    {% endfor %}  

  </aside>

```