3 ms·

I tried it out for a project and I regret it. Following reasoning: - CSS was created so no inline styling would be necessary. By assigning CSS attributes to cl

by xkcd1963 4y ago

I tried it out for a project and I regret it. Following reasoning: - CSS was created so no inline styling would be necessary. By assigning CSS attributes to classes we are back at inline styling. The html just explodes if you don't put the tailwind classes somewhere else, but then again, CSS is already here for that - one wastes time learning new naming conventions. Most frontend developers have internalised CSS attributes - it runs through a javascript lib. That makes the setup more complicated. Browsers support CSS natively so why build something on top of that

tomtheelder 4y ago
I think there's a chance that you're using it in a project it isn't suited to. For your first reason, component driven applications provide a compelling reason to go "back" to inline styling. You already have your abstraction, and adding another one (cascading styles) does you no favors. It just creates two interleaving re-usability schemes that are a nightmare to maintain in parallel. This is the same reason that component-local CSS has become very popular. Second one is a reasonable enough criticism. Never bothered me, but I think it's fair. Third: it's really designed for bundled, JS-based, component driven applications. In that context it's a breeze to set up, and really no more difficult than native CSS. By the way, the reason they do that is so it can do some clever things like removing the utility classes from the CSS that you actually ship to reduce payload size. There's no reason that you can't just build the entirety of Tailwind and just ship that as your CSS.
- jozzy-james 4y ago
  it isn't really _designed_ for JS based applications, but if you're not at least running vite/webpack/etc with PurgeCSS then your builds will be rather bloated and you lose out on customizing the settings - if you really just don't care, then you can run the default CDN build

tomtheelder 4y ago

I think there's a chance that you're using it in a project it isn't suited to. For your first reason, component driven applications provide a compelling reason to go "back" to inline styling. You already have your abstraction, and adding another one (cascading styles) does you no favors. It just creates two interleaving re-usability schemes that are a nightmare to maintain in parallel. This is the same reason that component-local CSS has become very popular. Second one is a reasonable enough criticism. Never bothered me, but I think it's fair. Third: it's really designed for bundled, JS-based, component driven applications. In that context it's a breeze to set up, and really no more difficult than native CSS. By the way, the reason they do that is so it can do some clever things like removing the utility classes from the CSS that you actually ship to reduce payload size. There's no reason that you can't just build the entirety of Tailwind and just ship that as your CSS.

jozzy-james 4y ago
it isn't really _designed_ for JS based applications, but if you're not at least running vite/webpack/etc with PurgeCSS then your builds will be rather bloated and you lose out on customizing the settings - if you really just don't care, then you can run the default CDN build