4 ms·

Exactly. The moment you start working outside of the React bubble you begin to discover just how many of these problems are solved by things like Svelte/Vue's

Exactly. The moment you start working outside of the React bubble you begin to discover just how many of these problems are solved by things like Svelte/Vue's single-file components and a few decent editor extensions. I don't have to go hunt for a separate CSS file to see what is happening with my semantically named classes. I don't even have to scroll to find it in the same file, I can just option-click the class and see a mini-window showing the relevant styles, edit them inline, or jump to where they are in code. I can find out which classes are unused or where they are used. I get the best of both worlds. Additionally the moment you get into anything beyond basic layouts the readability of Tailwind drops from "a little frustrating" to "completely opaque". Start adding new CSS features like variables, wide-gamut colors, sub-grid, etc and your neat Tailwind classes start looking like abstract [ ] and letter soup. Tailwind has some really cool benefits like helping you stick to consistent tokens from your design system and being able to copy paste most HTML from one project to another and have it work, but those benefits simply do not outweigh the downsides I find when I am working in a real project I have to come back to edit and iterate on with multiple people who don't all know CSS well.

danShumway 3y ago
> and being able to copy paste most HTML from one project to another and have it work coughweb componentscough I don't want to be derisive about it, but... yeah, agreed. I just feel like these are solved problems and Tailwind proponents are acting like it's novel that Tailwind helps with them. My immediate thought on hearing about even the benefits you bring up is that this doesn't seem like a realistic scenario? One of the stated benefits of Tailwind is that it addresses this concern that the HTML and code/logic and CSS aren't meant to be separated from each other and they interact so much. Well, given how tightly coupled HTML and logic often is, how often does it actually happen where you can copy HTML from one project to another and not have to reformat it from one framework into another -- if you're writing React you're already coupling that HTML to your code. If you're writing Svelte, you're using Svelte templates that won't be present in Vue. And if you're using CSS-in-JS, or heck, any scoped CSS solution at all then copying over that HTML means copying over the HTML and then... also hitting copy-paste on the block of CSS. That's not exactly a major time save. And even there -- how often am I going to import a block of HTML into a new project and not want to change the CSS to match a new style guide? There is a solution that allows you to basically import everything without worrying about whether it fits the rest of your application logic and styling though: web components. I don't personally get a ton of use out of them in my own development, but they seem basically decent and they seem like a much better solution if someone is worried about having a shared component library across multiple apps? --- I can't dismiss that there are developers that I respect who say Tailwind is great. I am not going to say that they're bad at CSS or they're inexperienced or something, that's clearly not the case. But I just wish they could explain what they're getting out of Tailwind in a way that I can understand. "You have to try it to understand it" -- I have tried it, I still don't understand it. It doesn't help that so many of these arguments start with "imagine not needing to worry about specificity." I haven't worried about CSS specificity in years.

danShumway 3y ago

> and being able to copy paste most HTML from one project to another and have it work coughweb componentscough I don't want to be derisive about it, but... yeah, agreed. I just feel like these are solved problems and Tailwind proponents are acting like it's novel that Tailwind helps with them. My immediate thought on hearing about even the benefits you bring up is that this doesn't seem like a realistic scenario? One of the stated benefits of Tailwind is that it addresses this concern that the HTML and code/logic and CSS aren't meant to be separated from each other and they interact so much. Well, given how tightly coupled HTML and logic often is, how often does it actually happen where you can copy HTML from one project to another and not have to reformat it from one framework into another -- if you're writing React you're already coupling that HTML to your code. If you're writing Svelte, you're using Svelte templates that won't be present in Vue. And if you're using CSS-in-JS, or heck, any scoped CSS solution at all then copying over that HTML means copying over the HTML and then... also hitting copy-paste on the block of CSS. That's not exactly a major time save. And even there -- how often am I going to import a block of HTML into a new project and not want to change the CSS to match a new style guide? There is a solution that allows you to basically import everything without worrying about whether it fits the rest of your application logic and styling though: web components. I don't personally get a ton of use out of them in my own development, but they seem basically decent and they seem like a much better solution if someone is worried about having a shared component library across multiple apps? --- I can't dismiss that there are developers that I respect who say Tailwind is great. I am not going to say that they're bad at CSS or they're inexperienced or something, that's clearly not the case. But I just wish they could explain what they're getting out of Tailwind in a way that I can understand. "You have to try it to understand it" -- I have tried it, I still don't understand it. It doesn't help that so many of these arguments start with "imagine not needing to worry about specificity." I haven't worried about CSS specificity in years.