Oof.
First off, it feels weird for the developer of NueJS to be throwing shade at other tools for "marketing and misinformation", given the number of articles I've seen extolling the virtues of NueJS as the silver bullet to solve all your problems.
Secondly, I think it would be useful for the author to reflect a bit on what Tailwind is doing that people find so useful. Obviously not everyone loves it (personally, I prefer writing CSS to Tailwind, just because it's a much clearer and expressive language), but it's clearly very popular, and the reason for that popularity is typically unlikely to be a conspiracy involving easy onboarding and lock-in.
I think understanding Tailwind on its own terms, with its own merits, is really valuable for understanding the state of CSS development right now, what works well, and what needs to improve. The author here seems to see Tailwind purely through the lens of being able to write CSS decorations: in Tailwind I might write `m-4`, but in CSS, I'd write |margin: 32px`, these are equivalent, so why create a whole extra tool just to do what we could already do?
To me, though, this is deeply missing the point of Tailwind. Tailwind isn't just a different way of writing CSS declarations, it's a way of tying those declarations to components. This is nothing new - it's the same concept as BEM, or CSS modules, or CSS-in-JS, or scoped CSS, amongst others. Essentially, when writing large projects with extensive CSS, most people run into maintainability issues, and most people seem to develop similar solutions: they tie styles to an already existing, more maintainable unit of code, namely the component.
I can go into the details of where these maintainability issues come from, and why components are such a nice solution, but if you've worked with large CSS projects, you probably already know that stuff, and if you haven't, I think BEM is a good place to start for understanding how to organise CSS, and why using the concept of individual components with sub-elements and different states is very helpful.
Understanding Tailwind on its own terms, then, we start to get answers to a number of the questions that the author asks. For example, they compare a JSX-style declaration `` to an equivalent with classes `` and ask whether the difference is just syntax. Well, let's analyse it from a component perspective: with the former, I know where the `Button` component is defined and can analyse it with my editor's code navigation tools, and I know that `plain` is scoped purely to that button. I also can't accidentally use `plain` from a button to annotate a checkbox - plain here explicitly refers to the button's "plain" style and it will not get applied elsewhere.
The same can also 100% be true in CSS - like I say, I'm not a huge Tailwind fan, and I personally prefer CSS solutions where they make sense. But it probably wouldn't look like the author has written it, it would probably look more like this: ``. That said, this still can have issues - the `button` class is completely global, and woe betide you if you forget it exists and try and define another `button` class somewhere else (or important one from somewhere else).
These questions of scope are hard ones to solve, which is why Tailwind exists alongside so many other, similar solutions. And I can fully understand why someone may not like the Tailwind solution specifically - its DSL for defining decorations is idiosyncratic, particularly if you're already familiar with CSS. But this article doesn't contrast Tailwind with those other tools, instead it compares having a solution for these issues with just not having a solution at all, and then tries to tell you that ignoring the problem is the better plan. I think that's a very disingenuous argument (possibly even an example of marketing and misinformation?) that makes the whole article very difficult to take seriously.