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 a way to create a design system 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 of 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 the frontend solely using inline CSS. Once I have everything ready, I start to create the CSS classes. Because then, I have a much better idea of how to organize them.
Inline styling is a tool that's needlessly been demonized. It's often much better than alternatives. And that's why TailwindCSS is winning.
Top comments (7)
Inline styles and utility classes are all very well until you need to update how something looks. Then you have to go through every page in turn and change the classes / styles on each individual element. When I was first learning about CSS (not that long ago), the main thing that was emphasised as an advantage of the language was the separation of styling from content.
To me, frameworks full of utility classes seem to be working against this and creating a nightmare for the future developer who has to change the way multiple components look. I can see the attraction of working with inline styling to quickly prototype a page, but it just looks like several steps backwards in terms of future maintainability.
Also, and as an aside: Surely utility class CSS is less efficient to parse for the browser? I can not imagine that having half a dozen classes on each element will not cause some form of slowdown on lower-powered devices. It might be a small difference, but I would like to see the load time of an identical page built using Tailwind and a more traditional CSS architecture.
The emphasis is itself wrong, because it fools the developer that writing modular CSS is easier. If you're creating the same CSS container for every small stuff, utility first CSS is a much better solution. There's a reason why Utility-first CSS has had a great uptake at big companies (e.g, Github, Adobe..), it's because they know how big of a mess CSS becomes at large codebases.
But, you're point is not wrong. Replacing classes can become a PITA and verbosity is just ugly. Luckily, you can always create classes and write custom CSS. I don't agree with Tailwind's approach, where you never have to write CSS. It's often a much better solution (e.g, paragraph spacing).
The answer lies somewhere in the middle. In most cases, utility classes would do the job and you won't miss much or anger the future developer. For things like buttons, links, paragraph spacing, it makes sense to have some sort of base styling.
Have to agree with this. There are a few points in the original comment that I take issue with:
Updating FE components: This seems to be a common complaint but I've rarely seen a situation where anyone actually wants to do this. "Well with CSS, I make a change in one place, and update the whole site." This is not only dangerous, because if updating the "whole site" is so difficult update, this inevitably leads to unintended consequences of things changing that you didn't expect. Sure changing a color is one thing. But how often is this even happening? The "difficulty" and intentionality of changing the markup is a feature, not a bug.
Rendering the markup: This is a bit of red herring. The rendered markup is endlessly changing and growing in an app. Massive amounts of data in a table to thousands of posts on a blog. The names of a few classes is orders of magnitude smaller than all the JS, CDN's, HD images, API data, etc... (not to mention the massive amounts of CSS) that often load in milliseconds already.
That all said, I don't think I agree with "There's 'nothing' wrong with inline-styles", there is plenty wrong. But I don't think they're wrong for the sake of it. And when used sparingly (read: as minimally as possible) it sure beats adding adding to a constantly growing stylesheet for one-to-two random use-cases.
Great article!
Can't fault your logic, just disagree with your premise here.
I do think that inline styles are inherently bad, (for the most part) but if you're fine with them, then I could see how TW might be a great timesaver.
A perfect example of why this was terrible was the horrible html generated by various ASP. Net components. It was all inline and then getting it to do something different became a huge battle of either configuration hell or overriding things with !important, I spent more time turning these things off that I just rolled my own components as user controls instead.
Inline styles have not been needlessly demonized. They really are appalling. The rather limited excuse provided here is practically a rare exception that proves the rule.
And even in the case here, it puts a whole bunch of work into putting the style information into the wrong place, you can't reuse it without writing new code. Even if you don't need to reuse the styles elsewhere it isn't any more work to separate concerns and let the html control which objects and text you are rendering and let the css styles control the appearance as gawd intended.
And besides my stylesheet contains a lot of simple reusable elements maybe yours should and that's why you think that inline styles are ok.
I used to use a page layout program that forced you to create a style for certain properties. It was not a bad thing, it forced you to use a design that was well conceived and editable while the gawdawful Microsoft Word lets users go hog wild with local overrides which are the equivalent of inline styles and the document quickly becomes an unmaintainable mess.
That depends a great deal upon how you measure productivity and over what kind of period. In my experience, it's the duct tape engineers that cost enterprise software companies in the long run.
Good job man!!