DEV Community 👩‍💻👨‍💻

Discussion on: Say no to Tailwind, embrace plain CSS

unsungnovelty profile image
Nikhil • Edited on

I agree with the markup getting crowded with the utility classes. While it is not recommend IIRC, you can create components and redirect it to a class name and use Tailwind CSS that way. But this issue and naming convention which is not needed cos you are not using components anymore anyways against:

  • Better DX (If you know CSS). You definitely need to know CSS for this framework unlike Bulma.
  • High performance. Load only used CSS. Nothing more or less.
  • Rapid UI development.
  • Knowledge transfer from CSS to Tailwind CSS is very less. You are not learning a whole new set of class names and how to use it. Instead you are translating it to well selected utility classes which provides a well designed design API. To me utility classes are aliases of CSS properties, for most part.
  • Learn CSS while using Tailwind CSS. This is just bonkers. I can't say this for any CSS framework.
  • You can configure the framework extensively. and use CSS properties which are not natively supported by Tailwind CSS. You can also use any values with any units you want even though your utility class doesn't have that value.

This means, if I want to use a CSS property which is not yet supported in Tailwind CSS,

  • I can use it like [clip-path:circle(50%)]. Voila! I just used clip-path property which is not supported in tailwind CSS. Configuring a CSS framework is a long and bumpy road in other frameworks. Also, it kills the whole point of using a framework because of the way it is designed.

Also the same way, I can use any values with any units with a utility class like

  • For width, w-[80%] or w-[90rem]. This means I can use a value outside of the default width values natively without hacks.

I don't know about you. For me pros outweighs the cons. You get the best of both worlds. A framework's convenience and CSS's performance. If you are using a CSS framework today, Tailwind CSS is one of the best if not the best. Like I said earlier, there is always a price to pay with abstractions. It is up to you to see if the pros outweighs your cons for your project/product. If it does, you should use it and don't, if it doesn't. :)