The section “Utility Classes: Yes, They Still Exist” is unfair in its comparison of Tailwind with pure CSS. It doesn’t take into account Tailwind’s recommendati

The section “Utility Classes: Yes, They Still Exist” is unfair in its comparison of Tailwind with pure CSS. It doesn’t take into account Tailwind’s recommendation in https://tailwindcss.com/docs/styling-with-utility-classes#using-components https://tailwindcss.com/docs/styling-with-utility-classes#us... that “if you need to reuse some styles across multiple files, the best strategy is to create a component” in your front-end framework or templating language. So its example of a “typical Tailwind component” is incomplete. A better comparison would use, for example, a React component: function Button({ children }) { return ( <button className="inline-flex items-center gap-2 px-4 py-2 rounded-full border border-gray-300 bg-white text-gray-900 hover:bg-gray-50 focus:ring-2 focus:ring-blue-500" > {children} </button> ); } // Usage: <Button>Save</Button> This would counter all of the article’s arguments in favor of pure CSS. If the website used a `Button` component like this, it would also be true that the “HTML stays readable”, that “changes cascade”, that “variants compose”, and that “media queries live with components”. A better argument against Tailwind would be the added complexity of having a build system and a front-end framework or templating language, if your project doesn’t already have those for other reasons. (adapted from my better-formatted comment at https://lobste.rs/c/oznzzj https://lobste.rs/c/oznzzj)