11–20 of 125 posts
Tailwind is write only, you’re not supposed to read it or maintain in. Want to change some property? Delete the entire class=“” attribute and start anew. Take that primary button example from the article - no one is claiming that it’s readable, especially when there are hundreds of primary buttons throughout the app, each with a slight variation. This works great for marketing or landing pages, or other use cases whe…
I prefer using plain CSS. I like semantic CSS and similar ideas of associating certain component class names with certain styles.
It’s not without its flaws - you have to learn a new syntax (which is in most cases very intoitive, e.g. “align-items: center” becomes “items-center”, “margin: 0” becomes “m-0” etc.) and it has its gotchas (for example it generates the css at build time by scanning your code and extracting classes you use to prevent generating unused css, which makes it impossible to construct a classname dynamically e.g. `gap-${value}`) but I take these issues over having to write CSS in any other way.
One point where I 100% do agree with the author though - you should first learn CSS before learning Tailwind. Not only because Tailwind could go away some day, but because this will give you a deeper understanding how and why stuff works.
Tailwind is write only, you’re not supposed to read it or maintain in. Want to change some property? Delete the entire class=“” attribute and start anew. Take that primary button example from the article - no one is claiming that it’s readable, especially when there are hundreds of primary buttons throughout the app, each with a slight variation. This works great for marketing or landing pages, or other use cases whe…
How’s that different than just writing plain CSS?
That is what CSS is. In the melee of “CSS in everything but CSS,” people might have forgotten what CSS is for. CSS’s classes are what you use everywhere again and again.
CSS Utility classes have been there for a long time and were made easy and famous by the likes of Bourbon[1]. They even have pre-defined styles — Neat[2].
Even though Tailwind can and should have been used more as what it was destined to do — utility classes. In a larger team, it is easier to stick to the TailwindCSS as such and have specialty/custom classes based on its utility for your project.
I was checking it out during its early release and introduced Tailwind to a team in 2018 who were stuck in Bootstrap. I wanted to stop hearing, “This is not part of Bootstrap.” The good thing I realized then was that if I followed a custom class with utility based on Tailwind, the result could continue to be the same with someone doing a “button button-blue button-large text-xl text-white.”
Btw, this too shall pass. I suggest learning CSS from first principles — everything that comes later will be another syntactic sugar. Remember, we started our projects with our grid layout that we stole from A List Apart’s faux-column layout, then came blueprint[3], bootstrap[4], foundation[5], bourbon, and now Tailwind, and every other one in between.
There was even a paid service (or a few, I think) that just churns out custom CSS grid layout code based on your drag-n-drop sliders.
Tailwind is a way to justify writing inline css in our HTML. This was once considered the cardinal sin of a frontend developer. You avoided inline-css at all costs.
But now Tailwind just makes a class for text-color-blue which simply abstracts the `text-color: blue;` css property away into its own class. But don't fool yourself, you are just writing inline css by a different name.
There is no way to explain how it is more maintainable to write `class="rounded button hover:bg-color-black-700 bg-color-black-400 active:bg-color-black-500 focus:bg-color-black-500 rounded-sm text-sm text-color-gray-300"` instead of just `class="btn btn-primary"` using the "old-school" semantic approach. I can list numerous advantages of the semantic approach here. The only advantages of the tailwind approach is that you can style as you go and you can see the resulting style in the HTML page.
Tailwind fanboys will say "it's easier to style in the html". But that's not true. Tailwind to be done right needs a fairly complex set of tooling to enable the hot-reloading, minification, and parsing into your pipeline. None of this is necessary with simple CSS. Semantic CSS "just works" with no tooling whatsoever.
Then again, I'm old enough to have contributed to the famous CSS Zen Garden back in the day. So maybe I am just an old curmudgeon. But like all things, I expect that Tailwind's popularity will wane. Remember that before Tailwind, everything was Bootstrap. The point is that whatever tool lets developers be lazy and avoid learning fundamentals will be the tool that prevails.
Your, "don't make things cleaner"/"make clean things", images show part of the Tailwind classes used to make the black button on one side and the class "primary" on the other. Elsewhere in the article you define "primary" as only setting the text color to white.
I believe the specific example is a strawperson argument - you're asserting that semantic CSS (as you've defined in the article) is better than Tailwind's approach. However, you don't show an alternative.
---
On a personal note, I've never seen custom (S)CSS written in a maintainable way in my ~decade writing it professionally.
Encapsulating styles by colocating them with the markup (Button.jsx and button.css, styled-components, Tailwind, etc) is the most maintainable way.
I think Tailwind works really well because it eliminates collisions at the global level and makes it really easy to see what a piece of markup will look like without having to change contexts.
As a fan of Tailwind's approach, I like to hear the other side.
Earlier quoted context omitted.
How’s that different than just writing plain CSS?
Tailwind limits the scope of your rewrite problem to the element you want to change. No fears about side effects on other parts of the page.
Earlier quoted context omitted.
I share your sentiment and position on Tailwind. My first introduction to programming was in 2003 as a 10 year old with HTML CSS and PHP. I think we will see Tailwind, like other frontend tech, fade into the sea of choices. If I had to summarize this I'd say don't fall victim to hype cycle and marketing. Make technical choices based on the problems. I've worked on teams where CSS was a mysterious language with many g…
I can also see how Tailwind can help teams that just want to move forward by copy/pasting ready-made components without ever looking "under the hood". However, I wrote this article for the love of CSS, web standards, and the web in general. I think Tailwind's dishonest marketing tactics aren't doing good for the development community. Especially for young developers who are suddenly told that things like separation o…
But in that instance, all of those css rules will still exist, but they’re stored in a separate css file and given a class name.
Having the reusability at the css class level means that someone else might break your component by updating the css.
With Tailwind, the reusability is at the component level. All the styles are self contained. No one can break your component accidentally.