This content originally appeared on DEV Community and was authored by Shubham Jain
A frequent criticism leveled against TailwindCSS is that it's just a fancy way to write inline styles. Usually, people counter by saying you can't create a design system with inline styles or limit the number of options.
However, I would say the idea is not far from the truth—TailwindCSS is just a nicer/shorter way to write inline styles, one that supports media queries and pseudo-elements as well.
The earliest implementation of Tailwind's approach I saw was in AtomicCSS. A framework I laughed off when I first came across it.
Tailwind introduces some design system ideas over pure inline styles, but overall the underlying ideas are the same. I see no reason why I won't be as productive with AtomicCSS as I am with Tailwind.
Once you let go off the notion that inline styles are inherently bad, you will become more accepting to Tailwind's ideas.
In the ideal world, we will have a frozen set of design components and we will never have to write CSS except on very rare occasions. The components are updated rarely and there's no ambiguity about what belongs where.
But the real world doesn't work that way. Here's what I have seen happen at companies:
- You write the same styles again and again (flex, font-sizes, spacing).
- You end up creating tens of container components that do the same thing.
- You try to generalize components, only for a new requirement to come in which throws your assumptions out the window.
- You create a Card component, but having to fulfill more and more requirements, you have made it so generic that in the end, it's just a white box with box-shadows.
- You want to reuse the style of the X component, but realize that your new component is called Y. So, you can't help copying the same styles again.
- The stylesheet has grown to more than a megabyte, most of it is composed of the same styling applied repeatedly.
- You want to use Modal component, but you see that it gives way too much padding. So, you write more styles to override them.
These problems are quite universal. Unless your team is really small, writing CSS the way people idolize is extremely hard. Often, it never works.
If the problem is so universal, maybe we ought to approach things differently.
Inline styles solve it perfectly. You can use the styles you want without worrying about components. If you see a common component emerging, just extract it. The team won't waste time writing CSS for stupidly simple things, thinking names, and discussing how to modularize the CSS code. The evolution would be organic.
Is it ideal? NO, of course. But, seeing the real-world scenarios, it's much better than alternatives.
It's just like refactoring. Time and time again, I have seen programmers who write duct-taped code, and try to clean it up later are much more productive than the ones who spend an entirety discussing the right approach.
https://twitter.com/davidwalshblog/status/1098960128794128384
Even when I am not using TailwindCSS, I approach building frontend by writing solely using inline CSS. Once I have everything ready, I create the classes. Because then, I have a much better idea of how to organize my CSS.
Inline styling is a tool that's needlessly been demonized. It's often much better than alternatives. And that's why TailwindCSS is winning.
This content originally appeared on DEV Community and was authored by Shubham Jain
Shubham Jain | Sciencx (2021-04-22T04:47:28+00:00) There’s nothing wrong with Inline Styles. Retrieved from https://www.scien.cx/2021/04/22/theres-nothing-wrong-with-inline-styles/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.