It's so odd to live long enough and see the steady pipeline of "look at this much simpler way of doing web apps, just write HTML, not like the previous complex way" projects, which then turn into the previous complex way as the eyes turn towards the next "simple way of doing web apps, just write HTML...". Angular and React started this way on the frontend, while ASP and PHP started this way on the backend (of course…
>The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline. Not my experience for the record. I use Tailwind in my side project, and it is exactly as convenient as it sounds to write my styles directly into HTML rather than think of a class name, add it in HTML, switch to the proper CSS file (or create it if it doesn't exist and make s…
> forget what name I had decided on
I think that's not the problem with CSS, but with how you approach design. If you treat your design process as editing a document, and just want to "Ctrl+B" to bold necessary parts, yes, I'm sure Tailwind's better. But, I can see how it could be a problem with maintenance and collaboration as there isn't an agreed upon design language or a document structure.
I understand that managing multiple files and going back and forth can be considered an overhead, but that's a componentization problem, not a problem with CSS per se, and you expect to recuperate your losses with the time you gained when finding and fixing bugs. Otherwise, there's no point in componentization. You'd have the same tradeoff when writing JavaScript code, for example.
You'd encounter the same set of problems the moment you start refactoring your styles into Tailwind components.