DEV Community 👩‍💻👨‍💻

Cover image for Say no to Tailwind, embrace plain CSS
Hayk Baghdasaryan
Hayk Baghdasaryan

Posted on

Say no to Tailwind, embrace plain CSS

Tools like Tailwind may help you develop your hobby project faster, but the thing is...

There shouldn't be any presentation logic in markup

You should use HTML to describe the content, hierarchy and structure, not how it looks. You should use semantic HTML tags like <section>, <aside>, <figure> instead of <div>. Then you style the content using the classes corresponding to the type of content, like "testimonials" instead of "bg-slate-100 rounded-xl p-8 dark:bg-slate-800".

That's why they removed a bunch of presentation tags from HTML, like <font>, <center> etc. Your website should be readable even without a single line of CSS/JS, only with the help of the right structured HTML. I encourage everyone to do some research on things like progressive enhancement and graceful degradation.

Benefits

There are tons of benefits in using HTML and CSS as they are intended to be used.

  • More accessible website,
  • better SEO,
  • performance improvements thanks to smaller HTML/CSS size and caching,
  • and you potentially avoid legal issues in future.

But... It's hard

Just because something is easier doesn't mean it's the right way to do it.

I get it, it's mentally draining to analyze the type of the content, name it correctly. But our job, as developers, is to do exactly that. Translate business requirements and domain knowledge to code, without ambiguity and without context loss.
It may be hard for some to learn CSS. The alternative? We learn a new framework, tool, library, utility every week. Learning and mastering CSS can't be much harder than that.

Conclusion

Tailwind may be great for hobby or POC projects. But for enterprise projects that tend to scale vanilla HTML/CSS is the way to go.

HTML and CSS are not perfect, but I'd rather we improve existing solutions, than come up with newer, shiny bad tools that try to solve the very problem they introduce.

Top comments (134)

Collapse
 
lukeshiru profile image
Luke Shiru • Edited on

Tools like Tailwind may help you develop your hobby project faster

So the thousands of products out there being built on top of Tailwind are hobby projects? 🤣 Atomic/Utility CSS is not something new, Facebook used it for years. This is one button they have:

Screenshot of CSS atomic classes on Facebook

You might notice every class, even if minified, has a single CSS property on it being set. Is pretty common to say "well, just inline CSS", but the thing is that utility classes aren't the same as inline styles.

There shouldn't be any presentation logic in markup

Says who? Following that logic you shouldn't use the class attribute at all. Using a classname "button-primary" is just a poor abstraction for presentation.

You should use HTML to describe the content, hierarchy and structure, not how it looks.

This is a very 90's style of writing HTML. We work with components nowadays, and those includes all kinds on concerns, including looks. Is important to handle correctly stuff like contrast, text size and interactions (mainly for a11y, but it affects everyone).

You should use semantic HTML tags like <section>, <aside>, <figure> instead of <div>.

We agree on this, but it has nothing to do with Tailwind. You can have a section with tailwind classnames, and you can have a div with the "button" classname on it. The tagnames you use have nothing to do with the classnames you use.

Then you style the content using the classes corresponding to the type of content, like "testimonials" instead of "bg-slate-100 rounded-xl p-8 dark:bg-slate-800".

That's the thing, we have Testimonials the component, not "testimonials" the classname nowadays. Both need styling. When we do it with React and Tailwind it looks something like this:

const Testimonials = props => (
    <section
        className="
            bg-slate-100
            rounded-xl
            p-8
            dark:bg-slate-800
        "
        {...props}
    />
);
Enter fullscreen mode Exit fullscreen mode

And yours without Tailwind would need some CSS first to achieve the same thing:

/* Testimonials.module.css */
.Testimonials {
    background-color: var(--slate-100);
    border-radius: var(--border-radius-xl);
    padding: var(--space-8);
}

@media (prefers-color-scheme: dark) {
    .Testimonials {
        background-color: var(--slate-800);
    }
}
Enter fullscreen mode Exit fullscreen mode

And then the JSX:

// Testimonials.jsx
import styles from "./Testimonials.module.css";

const Testimonials = props => (
    <section className={styles.Testimonials} {...props} />
);
Enter fullscreen mode Exit fullscreen mode

Do you actually see any kind of value in the CSS approach? And this is an ideal scenario in which we assume you use CSS Modules (when some folks are still doing global CSS) and CSS Custom Properties (when some folks generally just set every property).

That's why they removed a bunch of presentation tags from HTML, like <font>, <center> etc.

font and center where removed because they mean nothing for the structure, but this (similar to your point about using the correct tagnames) has nothing to do with Tailwind.

Your website should be readable even without a single line of CSS/JS, only with the help of the right structured HTML.

I think you found one of those sites that use div for everything with a bunch of Tailwind classes and thought that that bad practice was linked to Tailwind, but it isn't.

I encourage everyone to do some research on things like progressive enhancement and graceful degradation.

Some of us did a lot of research before choosing Tailwind, and that lead to use it. I used to dislike React because of JSX, until I understood that is just a small abstraction for function calls and fell in love with it. I also used to dislike Tailwind until I understood how beautiful it is to work with atomic/utility classes. Is almost like going from "classic inheritance" to "composition", you can never go back 🤣 ... now let's see those "Benefits"...

More accessible website

Accessibility has nothing to do with Tailwind (unless you really f*ck up colors and sizes, but you can do that with vanilla CSS as well).

better SEO

SEO has nothing to do with Tailwind, again. More often than not the bundle sizes end up smaller thanks to utility classes, so that will make your WebApp score higher.

performance improvements thanks to smaller HTML/CSS size and caching.

I mentioned it in the previous paragraph, but the bundles using Tailwind generally end up smaller, because you have way less code duplication. You just have as many classes as properties you set between all your components.

and you potentially avoid legal issues in future.

What? You might be talking about licensing, and Tailwind is MIT, and even if they change that in the future, you aren't forced to upgrade. This same thing could be said of any framework or library out there.

Just because something is easier doesn't mean it's the right way to do it.

"Work smarter, not harder". Easier doesn't imply better, but if you have two paths to achieve the exact same thing, you should chose the one that is easier. And in this case the easier one is also better 😅

I get it, it's mentally draining to analyze the type of the content, name it correctly...

I keep thinking about the comparison with "classic inheritance" vs "composition", because in the old days OOP folks would tell you that you need to invest more time thinking how to name a class and where to put every single method, and with composition is more like: Just write the code to solve the issue and put that together as needed. And I think that applies perfectly here. You could spend time thinking how to name your classnames to encapsulate "components", but you'll do that anyways when creating the actual components and just styling it as needed.

It may be hard for some to learn CSS. The alternative? We learn a new framework, tool, library, utility every week. Learning and mastering CSS can't be much harder than that.

Actually people prefer not to learn new stuff. There is a "JavaScript fatigue" because we get a new framework/library every day, so we tend to filter a lot of it. If we had the choice, we would use CSS only, but the thing is that CSS alone doesn't scale.

Tailwind may be great for hobby or POC projects. But for enterprise projects that tend to scale vanilla HTML/CSS is the way to go.
HTML and CSS are not perfect, but I'd rather we improve existing solutions, than come up with newer, shiny bad tools that try to solve the very problem they introduce.

Again, this is a really bad conclusion. Just google WebApps made with Tailwind or just atomic/utility classes and you'll see what I mean. Is actually way more common to see junior devs creating their first CodePens and similar using CSS only, but as they grow as devs they start using way more sophisticated and scalable solutions.

Cheers!

Collapse
 
andrewbogdanovtss profile image
AndrewBogdanovTSS

I can't agree more. I can say that your comment is better than the original article, lol )) I've been using Tailwind like frameworks on huge enterprise ecommerce projects with hundred thouthands of pages and I've seen only improvements when I moved whole thing to Tailwind. If I could name just one trully outstanding idea that appeared on the web in the last 20 years that would be Tailwind, it just changed everything for me.

Collapse
 
mellen profile image
Matt Ellen • Edited on

A class name isn't presentation logic, unless it is, in which case it's clunky and misleading. A class name should describe the content, on a meta level, e.g. "testimonial", not how you want the content to look, e.g. "bg-slate-100”. Describing how content should look is the job of CSS.

If you only use class names for presentation then you're missing the point.

Collapse
 
lukeshiru profile image
Luke Shiru

A class name is just one way (of many) of referencing an element, and it can be used from JS to set some relevant state or from CSS to style. That "class name should describe the content on a meta level" assertion is dogmatic at best. Not to mention that in 2022, we use libraries and frameworks to develop components to do stuff like Testimonial (as I pointed out in my comment with the Testimonials component example). You don't need a testimonial classname to have that component abstraction. Even if you go "full vanilla", you can still create a Web Component <testimonial /> so using class names for that is kinda pointless nowadays.

Tailwind, and other tools like it, enable "composition" with CSS, which if you have any experience in composition vs inheritance, you know is a good thing to have. Have you worked with Tailwind in a real world project or is this just "dogma" talking?

Thread Thread
 
mellen profile image
Matt Ellen

composition is great. i have yet to find a css library that makes css easier ro maintain. they all make css more complex and intricate.

Thread Thread
 
lukeshiru profile image
Luke Shiru

Try Tailwind on a project. Is basically CSS composition ☺️

Collapse
 
tbroyer profile image
Thomas Broyer

Facebook developers don't use such classes though, they're the result of tooling for technical optimizations.

Collapse
 
andrewbogdanovtss profile image
AndrewBogdanovTSS

Who cares how you name your classes, what matters is the aproach

Thread Thread
 
tbroyer profile image
Thomas Broyer

I absolutely never talked about the class names, but specifically the approach: engineering.fb.com/2020/05/08/web/...

Thread Thread
 
lukeshiru profile image
Luke Shiru • Edited on

lol don't show this to Op. It says they do CSS-in-JS which is what he's against, and it says they reduced the bundle size by using tools that turn that CSS-in-JS to atomic classes 😅

Thread Thread
 
tbroyer profile image
Thomas Broyer

The same transformation could likely be done from CSS modules rather than CSS-in-JS BTW, even possibly as a processing step on a statically generate site (or even server-side generated one if you're able to process templates).

Anyway, the point of "Facebook uses atomic CSS" is wrong, and the point of "don't use atomic CSS like Tailwind" still holds.

And I think this tooling/approach (CSS-in-JS mostly) works for Facebook because they're using components (see my other comment: dev.to/tbroyer/comment/20dfk)

Thread Thread
 
lukeshiru profile image
Luke Shiru

Anyway, the point of "Facebook uses atomic CSS" is wrong, and the point of "don't use atomic CSS like Tailwind" still holds.

Just because Facebook doesn't use it in dev, doesn't mean they don't use it at all (not to mention they still get the benefits), and it doesn't mean that only "hobby projects" uses it as the author implies.

Here's a Twitter button:

Screenshot of twitter classnames being atomic as well

Even if that's compiled as well, they are shipping atomic CSS to the users. Some devs like myself prefer to author the atomic CSS ourselves (ship what we wrote), and if you take a look at the popularity of Tailwind you might notice I'm not alone on this.

My question is: Have you actually try it on a serious project before bashing on it?

Thread Thread
 
tbroyer profile image
Thomas Broyer

Short answer before a more elaborated one: Twitter devs don't use atomic CSS either, that's the result of using React Native for Web: necolas.github.io/react-native-web...

Thread Thread
 
lukeshiru profile image
Luke Shiru • Edited on

Unless the long answer is to support the author of the article in his claim that plain CSS is better than atomic/utility classes, don't bother. You're only pointing out that my examples are using it as a compilation target or result of a build process, which isn't an argument to support the author (is more like an argument to support the benefits on size/performance of atomic CSS).

You're doing a separate argument about using atomic CSS in dev vs using only as a target, and that falls in a coding style category (almost like tabs vs spaces). Me (and many, many others) prefer to use it on dev with Tailwind, while Facebook, Twitter and others have it as a prod target.

Collapse
 
samantrags profile image
Raghavendra Samant

This comment is more useful than the article

Collapse
 
haykerman profile image
Hayk Baghdasaryan Author

@lukeshiru I get your points, I know the problems you've encountered and why are you using the tools you are using today. I'm just proposing a better solution.

It was not mentioned once in the post that the projects using Tailwind are hobby projects. The article suggests only using it on hobby projects.

If Facebook or any other tech giant uses X, it doesn't mean that X is the right or optimal way to do it. I doubt it they would use it again if they were to rewrite the platform (I'm being optimistic about the professionalism of their dev team).

I don't know about the "very 90s style", but you should definitely check out the modern version of W3C Recommendation on element semantics. It highlights the importance of using semantic HTML for creating a accessible website.

This semantic information is critical to assistive technologies. For example, a screen reader will query the browser for semantic information and use that information to present the document or application in synthetic speech.

In some cases assistive technologies use semantic information to provide additional functionality. A speech recognition tool might provide a voice command for moving focus to the start of the main element for example.

When the appropriate HTML element or attribute is not used, it deprives HTML processors of valuable semantic information.

Also, take a look at the note about classes from HTML Spec Standard.

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

These are basically documentation for "how to properly use HTML/CSS".

As for the modern ways of building websites without sacrificing maintainability, scalability and accessibility: you can create your components using Web Components Suite combined with CSS modules. And you will be able to follow the class naming convention suggested by HTML Standard. Or you can even ditch the class usage and use the CSS type selectors to target and style the custom element.

Yes, as of now the Web Components are not fully supported by some browsers (source). But I really believe we need to push the wide adoption instead of creating alternative solutions for those problems.

Collapse
 
lukeshiru profile image
Luke Shiru

I'm just proposing a better solution.

"Better" based on what?

The article suggests only using it on hobby projects.

No difference between "suggesting" and "proposing", it is still wong.

If Facebook or any other tech giant uses X, it doesn't mean that X is the right or optimal way to do it. I doubt it they would use it again if they were to rewrite the platform

You really underestimate the power of tech giants. They can rewrite whatever they want. Facebook wasn't built initially in React, now it is. It didn't used GraphQL, now it does. Atomic CSS is a compile target of their CSS, so if they wanted to ship something non-atomic, they would definitely do so, but they chose to ship atomic CSS because is optimal.

It highlights the importance of using semantic HTML for creating a accessible website.

Your post says: "You should use HTML to describe the content, hierarchy and structure, not how it looks", and the W3C in that first link is talking about semantic HTML. Me and many developers in the comments already told you that you're mixing two different things here. You can have amazing usage of semantic HTML with Tailwind, and a DOM made of just divs using a single "descriptive" classname like you suggest. There's no correlation. W3C is talking about tag names, we are talking about class names.

Also, take a look at the note about classes from HTML Spec Standard...

Let me highlight a few things on your own quote of the HTML Spec:

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

Is not a rule, is a "suggestion", and a pretty outdated one (not to mention is there since before 2018, and Tailwind 1.0 was released in 2019).

These are basically documentation for "how to properly use HTML/CSS".

These are "standards", and they are far away from being the "proper way" of doing anything. Just take a look at native Web Components and you'll know why folks prefer libraries and frameworks over what the "platform" offers or suggest. Which is funny because you suggest using that next ...

As for the modern ways of building websites without sacrificing maintainability, scalability and accessibility: you can create your components using Web Components Suite combined with CSS modules

... and I say is funny because supposedly your point about not using atomic/utility CSS is that we should stick to use semantic HTML, and class names that represent the actual elements, so something like this:

<button class="primary-button">Hello</button>
Enter fullscreen mode Exit fullscreen mode

Yet using web components we actually end up with something that isn't accessible or uses class names to represent the actual element:

<primary-button>Hello</primary-button>
Enter fullscreen mode Exit fullscreen mode

Or something that achieves the same in a less supported and less efficient way:

<button is="primary-button">Hello</button>
Enter fullscreen mode Exit fullscreen mode

Yes, as of now the Web Components are not fully supported by some browsers (source). But I really believe we need to push the wide adoption instead of creating alternative solutions for those problems.

The problem goes beyond browser support, and to be honest I entertained this argument of yours long enough, when it goes against your own "benefits":

  • More accessible website: Custom elements affect a11y negatively, and generally you end up re-implementing stuff that already comes supported with native HTML.
  • Better SEO: SEO is actually worst with web components because crawlers have a harder time understanding the structure of the page.
  • Performance improvements thanks to smaller HTML/CSS size and caching: You're loading a JS file for something that could be just HTML and CSS.
  • Potentially avoid legal issues in future: I still find this point of yours puzzling, but if you're consuming Web Components made by others, then you could have the same "potential licensing issues" you could have with Tailwind.

So suggesting Web Components goes against all your "benefits", and they are event worst than Tailwind because they require JS to work.

The most important question of all that I think you didn't answer is:

Have you actually used Tailwind on a real world project? Or is this just the dogma speaking?

Cheers!

Thread Thread
 
haykerman profile image
Hayk Baghdasaryan Author • Edited on

If you consider what the article is suggesting wrong, do your own thing. There are multiple reasons why I consider the article's suggestion more suitable, and some of them were highlighted. You are free to disagree.

Of course, tech giants CAN overwrite anything they want, but DO they? I wonder why is that...

I don't get how someone can consider those standards outdated. If they're not updated it doesn't mean they are outdated. It is more like, if it is unchanged, then the standards are still up to date.

No one is preventing you from creating horrible components like <primary-button> (if you don't see what's wrong with it, well...). If someone doesn't know how to use the tool, doesn't mean the tool is to blame. I agree that the Web Components Suit is not perfect yet and is relatively new, I'm suggesting to perfect it, because I think it's the right path to take. Standardize the solutions, instead of creating new bad solutions that try to solve the same problem.

I have used and am still using (unfortunately) Tailwind on an enterprise project. I don't get how can someone justify the use of something that uses pixels instead of relative units for breakpoints, but at the same time uses relative units for font sizes, is slopping a ton of duplicate classes in markup, makes HTML longer to load and makes it barely unreadable for devs, breaks the caching model and the list goes on.

But if it's your cup of tea, go for it.

Thread Thread
 
lukeshiru profile image
Luke Shiru • Edited on

If you consider what the article is suggesting wrong, do your own thing.

I'm not the only one, you can check all the other comments that consider that your take is bad, not to mention that my comment got almost 100 likes, so yeah...

There are multiple reasons why I consider the article's suggestion more suitable, and some of them were highlighted. You are free to disagree.

I know I'm free to disagree, that's why I explained why your "benefits" are just wrong.

Of course, tech giants CAN overwrite anything they want, but DO they?

Yes, I gave you an example. Twitter is other giant and it was also re-written in React. If they think the tech they have has something bad, they just re-write stuff. And as I mentioned they can just change a build config and get normal CSS, but they chose to deliver atomic instead (because it reduces the size of CSS drastically).

I don't get how someone can consider those standards outdated. If they're not updated it doesn't mean they are outdated.

That's literally the definition of outdated. There are lots of technologies that came after those docs were created, some demonstrates that the suggestion of using classnames in that way are not great. Yet the docs are still not updated.

No one is preventing you from creating horrible components like <primary-button> (if you don't see what's wrong with it, well...).

It was an example, it could be <fancy-button type="primary" /> or some thing like that, the point wasn't that (if you don't see the point, well...).

If someone doesn't know how to use the tool, doesn't mean the tool is to blame.

Exactly what I thought when you later said:

I have used and am still using (unfortunately) Tailwind on an enterprise project. I don't get how can someone justify the use of something that uses pixels instead of relative units for breakpoints, but at the same time uses relative units for font sizes, is slopping a ton of duplicate classes in markup, makes HTML longer to load and makes it barely unreadable for devs.

Tailwind at work and in personal projects has been great, but we know how to use the tool, so....

Standardize the solutions, instead of creating new bad solutions that try to solve the same problem.

Yeah. Because that always goes so well! Even the folks that love web components don't recommend to use them directly, but instead use a framework or library because the vanilla experience is horrible. Those "new bad solutions" you mention will always be there, because the platform will never be on par with the requirements of the industry.


I love how I keep addressing everything you say while you just focus in some stuff and avoid other topics.

  • I gave you an example of how tech giants change tech, you ask if they really do it when I already told you they do.
  • I told you several times that you're mixing semantic HTML with class name definitions and you avoid that topic constantly.
  • I told you that your "benefits" are wrong and the reasons behind that, you avoid the topic yet again.
  • You insist on web components when they are against your own points "against" Tailwind.

You like were Web Components are going and you don't like to work with Tailwind, that doesn't mean that Web Components are good or that Tailwind is bad, it only means you have personal preferences and experiences. The problem is that you present that as facts/standards, when you're just using the standards as mean to justify your personal preference.

I'm really tired of repeating the same things in every comment, and just get responses for what you find convenient to keep arguing, so I'll leave it at that. Any other thing I could say about the topic to help you understand the benefits of Utility/Atomic CSS you can Google yourself.

Cheers!

Collapse
 
mangor1no profile image
Mangor1no

This comment should be a separated article. Couldn't agree more with the points in the comment. TailwindCSS makes our life as developers much easier, although yes the HTML is bloated with irrelevant class names. However, who the heck cares about the class names beside us? And yes, we are not naming our class names to something meaningful, but do it to our components insteads. And the idea about TailwindCSS is ruining people knowledge about CSS is very wrong, in fact you can learn how CSS works from it (yes I'm not kidding).

Collapse
 
mkvillalobos profile image
Manrike Villalobos Báez

Absolutely agree! Your comment is, indeed, very insightful and explain the reason why Tailwind, and other frameworks and tools that implement Atomic CSS exists, are popular, grows, evolve and have a huge ecosystem! Is not perfect, I realize that, but helps to solve a problem that CSS hasn't couldn't in the development community, specially in way that now we construct components to build pages and web applications using composition!

Collapse
 
banesto profile image
Ernests Kečko • Edited on

This should be posted as an opposing article as it has more substantial basis than original post, IMHO.

I haven't used TailwindCSS, but I have been inspired by it's utility classes paradigm. By refactoring only a fraction of CSS/HTML I managed to decrease CSS footprint by at least 30% in production! TailwindCSS removes all unused classes from production bundle automatically, but my setup is not so elaborate as I've been adding only those utility classes that are actually being used - which lead to certain minimalism in a way I chose my classes in UI, so CSS footprint is even smaller.

The main goal of refactoring was to improve SEO ranking (markup already uses main/section/footer/header and others), the main problem was the file size of CSS/JS. So using utility classes paradigm was certainly invaluable to attain those goals!

The only downsides are the initial know-how of the names of the classes you need to add to selectors to gain needed effect, but once you get it, development is super easy as you just need to add needed combination instead of adding new CSS. Lots of features being added after said refactoring did not require adding new CSS at all.

Another downside is that developer needs to maintain utility class hygiene as not to add new one which is used rarely.

Regarding production vs hobby projects. I think for hobby project dev can use whatever he wants, but as for serious production, maintainability is really important. It's much easier at least for me to do classic CSS with cascading, but maintainability is non-existent there as speed is the king there and code duplication is all over the place. With utility classes maintainability is kept at high level by not introducing new CSS all the time. The bigger/longer the project, the more sense to use utility classes on it.

I think OP's point is something along the lines of "knife is being used to kill people therefore knife is bad and should be banned". Every tool can be misused, but if used wisely, it can be of invaluable help.

Either way, these are my 2 cents.

Cheers!

Collapse
 
amirhd_dev profile image
AmirHD

I really enjoyed it, you explained it very well and completely👌🏻👏🏻👏🏻 Tnx a lot 🙏🏻

Collapse
 
aguilera51284 profile image
Arturo Aguilera

this kill the original post xD

Collapse
 
cordial profile image
cordial

This should be the article.

Collapse
 
sebastianinman profile image
Sebastian Inman

Fucking thank you.

Collapse
 
bobgravity1 profile image
bobgravity1 • Edited on

no. tailwind is like cheating and it makes it a nightmare to truly build a fully customizable styled components

Collapse
 
lukeshiru profile image
Luke Shiru

Tell me where you struggle and I will tell you how to solve it:

  1. "Is like cheating": As developers we constantly look for "cheats" to make our lives easier, so that's a good thing.
  2. "Makes it a nightmare to build fully customizable styled components": How? You just have a few base styles, and you make it extensible by using tools like classnames or tailwind-merge.
Collapse
 
intrepidd profile image
Adrien.S

The ratio tells everything

Collapse
 
unsungnovelty profile image
Nikhil • Edited on

Edit: Maybe I should add the fact that I moved my personal website from Bulma to Tailwind CSS which was 12726 lines of CSS to 805 lines of CSS. Which made my stylesheet go down from 247.1kb to 13kb. I already have had tried to use the minimum possible in Bulma. With Tailwind CSS load only the used CSS.


As a perfectionist, I am very picky when it comes to my choice of an abstraction layer. Tailwind CSS has been a great abstraction layer IMO. I wrote about it here as well - dev.to/unsungnovelty/explaining-wh....

But our job, as developers, is to do exactly that. Translate business requirements and domain knowledge to code, without ambiguity and without context loss.

This. Our job's to translate things to solutions. HOW we do it is irrelevant. A lot of companies (Especially VC funded), nor the end users care which tool we used. All they could care is whether they get what they want, the way they want it, by the time they want it. That is it.

But... It's hard

There is also something called Pit of success which was coined by Jeff Atwood. CSS is a perfect example of a tool which instead of directing you towards pit of success, directs you towards pit of despair. In short, a tool/technology/language by default should make it hard for you to fail and direct you towards success. And CSS is an example of pit of despair. And IMO, Tailwind CSS makes it much more manageable.

I love CSS as a technology. When I have time, I still write plain CSS to brush up my skills. I love CSS Grid a lot. But I would be lying if I say CSS is not a PITA. Also, Tailwind CSS still makes you think in CSS as I mentioned in the blog. Unlike component based CSS frameworks, for working with Tailwind CSS, you still need to know some CSS at least. And as you work with it, Tailwind CSS helps you learn plain CSS. Whereas component based CSS frameworks like bootstrap and bulma makes you forget what you know in CSS. It is far better than navbar classes IMO.

Personally I understand where you are coming from. At least I think I do. Cos I used to think similarly. But it's all about balance. And the right tool is extremely subjective based on your requirements and the time you have to name a few. :)

Collapse
 
haykerman profile image
Hayk Baghdasaryan Author

A lot of companies (Especially VC funded), nor the end users care which tool we used

This is the biggest part of the problem I've personally experienced. If they don't care, we're the only ones remaining who should still do, ideally. I don't suggest throwing out all existing frameworks right now and going Vanilla. I just advocate for using it more, improving it or at least trying to stick to best practices. Because clearly, the direction we're going right now is concerning.
I agree that it's all about balance, and using the right tool for the job.

Collapse
 
unsungnovelty profile image
Nikhil • Edited on

I just advocate for using it more, improving it or at least trying to stick to best practices. Because clearly, the direction we're going right now is concerning.

That is a good POV. End goal being plain CSS. The utility classes does crowd HTML markup. Which is my only problem with Tailwind CSS so far. But developer experience Tailwind CSS provides is better for me though. And with components based frameworks like Bootstrap, I pay a lot in performance.

With Tailwind CSS, I bundle only what I use. So as a dev, I am more happy thanks to the developer experience (DX) and performance. So the truth is, at least for a some time, I don't see a reason to go back to plain CSS or component based frameworks.

Thread Thread
 
prototowb profile image
Tobias Rauer

Yes, tailwind can be nice for POC.
Although, tailwind let's you forget how to name things properly, and adds a big mess of obfuscated elements, and thus should never be used in production or just projects that scale.

Thread Thread
 
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. :)

Collapse
 
hollyw00d profile image
Matt Jennings

Nikhil,
You mentioned "Our job's to translate things to solutions. HOW we do it is irrelevant.".

I wouldn't quick necessarily agree with that because if dev A creates very confusing, hard-to-update code when dev B is working on it that's an issue.

However, if dev A creates code that is considered a "hack" by some developers but still gets the job done and isn't dangerous and dev B can update it that's OK.

Collapse
 
unsungnovelty profile image
Nikhil • Edited on

Hey Matt,

I think you missed an important part which went along with the quoted statement. I said it is irrelevant to the employers and end users. I wasn't talking about developers.

The scenarios that you mentioned as well, both the scenarios are relevant to the developers. Not necessarily for the employers or end users as I mentioned earlier.

A website with the mentioned first scenario can succeed and the second scenario can fail if the translation of solutions and business doesn't go well. Also vice versa. I definitely agree with you on the fact that the developers should write clean and understandable code. And that we should avoid magic and hacks as much as possible.

But with regards to the topic at hand, I don't think Tailwind CSS is a hack. Also, it actually teaches plain CSS and provides performance while doing it. I cannot say the same for component based CSS frameworks which are always a performance hog and makes you forget plain CSS. They only provide performance value when they can be utilised to the max, which mostly will be in a large project. Otherwise there is a performance tax.

Apart from the utility classes crowding the markup, I don't see any problem here. Not to mention if you want, you can make those into components and use it that way. The official typography plugin also provides sane defaults to many html elements through prose utility class. So for me, the pros outweighs the cons by many a mile. But that is just my use case. I don't think one abstraction layer can make everyone happy. And that is fine. It's the same reason why we have many choices. :)

Thread Thread
 
hollyw00d profile image
Matt Jennings

Hi Nikhil,

I heard you say "Our job's to translate things to solutions. HOW we do it is irrelevant." Yet, I still believe that code solutions are still relevant to managers if trying to edit or add to the current code is extremely difficult and time confusing.

So yes, managers should definitely know in a general and easy-to-understand way if a previously created code is time confusing to add to or edit.

But, if code is structured in a way that's easy to edit and can be scaled up, then managers don't need to know as many details.

Collapse
 
jsn1nj4 profile image
Elliot Derhay

Unlike component based CSS frameworks, for working with Tailwind CSS, you still need to know some CSS at least. And as you work with it, Tailwind CSS helps you learn plain CSS.

This is something I've experienced too. I've even found myself going back to Tailwind's docs for looking up something about how CSS works (e.g. the different parts of flexbox).

Collapse
 
patiodaddiobbq profile image
John Dawson • Edited on

A self-proclaimed perfectionist uses “Cos”; oh the irony! 😉

Collapse
 
unsungnovelty profile image
Nikhil

I completely missed this comment! :D

Collapse
 
gorango profile image
Goran Spasojevic

I couldn't disagree more.

Being dogmatic in a fast-changing industry will only leave you in the mud shaking your fist at everyone else who's moving past you.

I recently migrated a large project from pure CSS to Tailwind - not only did we see huge performance improvements, we also improved development time and maintainability of the whole project. New devs no longer have to learn naming conventions or discover where CSS rules are being declared.

If you want to use plain CSS in your pet project, go for it. But don't shove these ideas down people's throats just because you have ideological oppositions to a new paradigm.

Collapse
 
haykerman profile image
Hayk Baghdasaryan Author • Edited on

If you had performance, maintainability problems with plain CSS, it's not the CSS. It's the developers, engineering managers, and their ignorance towards best practices. And maybe, just maybe, unrealistic deadlines.

If new devs are having problems with CSS, there can be multiple reasons: the conventions were not properly communicated, the information was not publicly available, the onboarding process is not well thought out or last but not least, devs weren't qualified enough. And I don't blame them. It's just the current state of the world.

Now, granted, CSS is not perfect, but it's constantly improving with additions like variables, CSS modules. I am not shoving ideas down peoples throats, people are free to criticize my methods, as long as the criticism is objective. Also, I encourage critical thinking. The post above is just my take on things, and my opinion on how we should move forward. Everyone is free to disagree.

And, there are no dogmas, just some experience sprinkled with common sense. I'm pretty open minded. If you have a better solution, or you have your own take on the situation, I am happy to hear it. Because improving what we currently have is a collective effort.

Collapse
 
nexxeln profile image
Shoubhit Dash • Edited on

Very bad take, if you don't like tailwind, thats understandable, but shoving that opinion down everyone's throat?

More accessible website

How does tailwind hurt accessibility?

better SEO

Huh? It's a CSS framework how will it hurt SEO performance? I don't think you know how Tailwind works. Tailwind creates a stylesheet at build time based on the classes you used. Therefore these is very less unused CSS, hence performance is very good. This will only boost SEO no?

performance improvements thanks to smaller HTML/CSS size and caching

What? Tailwind will almost always create a smaller CSS file in a large scale project.

Tailwind may be great for hobby or POC projects. But for enterprise projects that tend to scale vanilla
HTML/CSS is the way to go.

So you're saying Deno Deploy, PlanetScale, Ping.gg and hundreds more are hobby projects?

Never seen a worse and more incorrect take on Tailwind lmao.

Collapse
 
haykerman profile image
Hayk Baghdasaryan Author

Thanks for your feedback :)

Collapse
 
jafuentest profile image
Juan A. Fuentest Torcat

LOL no one's shoving anything down anybody's throat. At least not in this post.

Collapse
 
nexxeln profile image
Shoubhit Dash

The title is "Say no to Tailwind, embrace plain CSS" lol. Please read the post before commenting.

Collapse
 
dhravya profile image
Dhravya

yeah, i completely agree with this! Please research before writing this type of blog, because many beginners will be negatively influenced by this.

Collapse
 
andrewbogdanovtss profile image
AndrewBogdanovTSS

Can't agree more. We live in the era of blind people being guided by the blind people and unfortunately all those people have access to internet and time to write articles.

Collapse
 
t3dotgg profile image
Theo Browne

Good take

Collapse
 
fkranenburg profile image
Ferry Kranenburg

Classes are attributes of html elements. Tailwind classes are not html elements like font or center, so you can't compare them like you do. I don't think many front end developers are building pure html and alongside css elements. Who does that anyway? 'Components' in whatever framework you use, that include encapsulated styles, is the future an the way to go nowadays. Personally also not a fan of Tailwind but classes are still part of common html sematics.

Collapse
 
haykerman profile image
Hayk Baghdasaryan Author

Sorry if my post was not clear enough. I am not against using classes, I am against using presentation classes. I prefer "navbar", "features", "testimonials" over "bg:blue", "text-center". The markup should not contain information about how something looks.

Sure, Tailwind provides classes, not tags. But, be it a presentation class like "text-center" or a <center> tag, I think neither is acceptable or semantic.

Let's agree that "Who does that anyway?" is not a very good justification against doing it.

Using frameworks is not the only way to create websites. What happened to Vanilla JS? Almost everyone today creates websites using frameworks and component libraries. I don't think this is the way to go, though I understand why and how we got there. Honestly, this can be a topic for another article.

Collapse
 
lukeshiru profile image
Luke Shiru

I am against using presentation classes. I prefer "navbar", "features", "testimonials" over "bg:blue", "text-center". The markup should not contain information about how something looks.

That distinction is quite irrelevant, because we don't create components from CSS, and even if we did, the styles are still attached to those classnames. If you really prefer that approach, you can still use @apply in Tailwind:

.button {
  @apply inline-flex items-center px-6 py-3 border border-transparent text-base font-medium rounded-md shadow-sm text-white bg-indigo-600 hover:bg-indigo-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500;
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
joshwcorbett profile image
Josh Corbett

Yes, Javascript frameworks are not the only way to build websites, but they are the best way right now. Tailwind isn't being marketed to individuals building straight vanilla html/css/js sites, it's more for those where functionality takes center stage over styling than anything. Being ignorant to the way new web technologies and practices are evolving is only going to hurt your future projects and skill set down the line.

Thread Thread
 
haykerman profile image
Hayk Baghdasaryan Author • Edited on

I've been and still am using those frameworks while working on multiple enterprise projects. I've experienced both pros and cons of those. I'm well aware of current trends, I've been closely observing the evolution of the web development, tools and methods for more than 5 years.

If you think this post is intended to just trash current tools and technologies, read again. While highlighting the weak points of a popular tool, this post is about wondering if there's a better way, and pushing innovation in the right direction while preserving established best practices. The intention is far from being ignorant. On the contrary, it's about caring enough to attempt improving what we already have today.

Without any doubt, how we're creating websites today is sub-optimal at best. Huge bundle sizes, millions of tools and dependencies, slow, not-accessible, unmaintainable websites. And the list goes on.

If you consider yourself a decent software engineer and take pride in being one, you should try to be professional enough to create quality products. But that's my take on the matter. Ultimately, it's just a matter of priorities. If you're just focused on making money, moving up the career chain, or surviving given the current state of the software engineering world, this discussion is pointless.

Either way, I wish you success, and I hope someday you will join me in an attempt to improve and perfect the technology, which will lead to the creation of amazing, performant and accessible products, the better web.

Thread Thread
 
fkranenburg profile image
Ferry Kranenburg

I don't think you really have a good view on how we noways should build good, nice, userfriendly and dev maintainable websites. Bundle sizes exceed but we also have more bandwith, faster devices an we need to add lots of features to compete with the competition. It is just how it works. But if you see unmaintainable websites using modern technologies than you are doing it completely wrong. In my 20 year web dev experience I watched us fighting various browser related issues (IE) and trying to get things work cross browser just by using lots of old hacks. I'm glad those days are mostly over because of our new much improved set of tools all self respecting developer should use today.

Collapse
 
fkranenburg profile image
Ferry Kranenburg

I agree on most parts, maybe I don't understand the difference between classes and presentation classes. I'm sure all classes are meant for presentation. But how Tailwind let's you add lots and lots of separate classes for displaying 1 html component is mostly very confusing an time consuming while fixing issues with styling. And it makes the pure html harder to read.

I try to stay away from 'Vannilla JS' written websites because nowadays using reactive frameworks, typescript, reusable components, scss makes my work a lot easier, less buggier, and takes much less time to build. Great article btw 👍

Collapse
 
alohci profile image
Nicholas Stimpson

Yes. Of HTML semantics. i.e. The meaning of the content. Presentation information should not appear in HTML classes.

Collapse
 
sebastianinman profile image
Sebastian Inman

According to who, exactly?

Thread Thread
 
tbroyer profile image
Thomas Broyer

Everybody for the last 20 years or so? …until people started reinventing inline-styles with "utility" css frameworks (the whole idea of "css frameworks" is…)

Collapse
 
rodrigomata profile image
Rodrigo Mata

I completely disagree in two main things:

  1. You are basically saying that using Tailwind means using semantically incorrect HTML, those are two separate things. You can be using plain HTML+CSS and still use pure divs, so I would emphasize on that and make a distinction, using Tailwind is not related to writing bad HTML code

  2. In your conclusion you say that it is used for projects that don't scale. It's totally the opposite. Tailwind is made exactly for projects that scale, specifically for those that have a color palette, themes, dark mode, responsive, accesibility. Handling all of those features in plain CSS is not only hard to maintain but more error-prone. Tailwind uses PostCSS which will also autoprefix your classes to support a variety of browsers and also will analyze the classes and remove from the production build those that aren't used. This is super helpful in production-enterprise-big projects, because saving a couple of KBs translates directly into money.

I can sometimes feel you that in order to make something production ready today, a lot of extra tools are needed, but that's the complexity of web development: supporting too many devices, screen resolutions and being performant and styled at the same time. In order for us to be able to use plain CSS and JS IMHO, we would need a new CSS and JS that is not backwards compatible, because that's the main problem, and in order to do that, you would need the reinvent the wheel. And there's nothing wrong with that, take Adobe Flash for example, it is now deprecated.

Collapse
 
haykerman profile image
Hayk Baghdasaryan Author • Edited on

Completely agree on the 1st point. The semantic HTML pitch was practically an extra. I can see how someone reading the post may get an impression that using Tailwind is associated with writing bad HTML. My bad. I will try to edit it.

Somewhat agree on 2nd point. I never said that Tailwind is used on projects that don't scale. I suggest using it on smaller hobby or proof of concepts project. I agree that it may be easier to scale with Tailwind. I'm just implying that the cost of using it may be more than the advantages it provides. Of course it's just a tool, and it has it's advantages.

Basically this article turned out to be a little bit cheesier than anticipated. I think your take on this is healthier and more balanced. I appreciate the contribution and constructive criticism.

Collapse
 
andrewbogdanovtss profile image
AndrewBogdanovTSS

I really can't understand what "costs" you are trying to point to here? No one will crucify you if you write md:flex in your html

Collapse
 
thomasbnt profile image
Thomas Bnt

Oh, thank you for your article. 🙏🏼

I am currently working on a project that I have taken over. The team is using Bulma (same as Tailwind), and when I see that a class is called title only to give the font-size and two three parameters more, it makes me shiver.

Why do this knowing that there are already semantic tags...?

Collapse
 
lukeshiru profile image
Luke Shiru

Tailwind and Bulma are completely different. Tailwind is utility CSS, while Bulma is component CSS (which the author of the article you're thanking actually likes). A pretty common mistake is to glance over Tailwind and assume it is "like Bootstrap", when they are very very different. I recommend you actually try Tailwind out on a real project before agreeing with this author ☺️

Collapse
 
thomasbnt profile image
Thomas Bnt

Whether the author likes Bulma or not, this is not where I thank him. It's the fact that classic CSS does the trick.

And in no case I'm talking about Bootstrap, why compare at all? 🤔

Thread Thread
 
lukeshiru profile image
Luke Shiru

Bootstrap IS like Bulma, Tailwind isn't. So comparing it with Bulma is pretty much the same thing.

Thread Thread
 
thomasbnt profile image
Thomas Bnt

I just read some comments, it's a fighting game! 😲

However, I didn't know that TailwindCSS minimizes resources and removes unused classes. That's a good thing. 👍🏼

This is a bad take.

First off, CSS libraries like Tailwind have absolutely nothing to do with the semantic markup of the HTML content, so bringing that up is a totally moot point.

As far as "better SEO" and performance is concerned, Tailwind, out of the box, removes any unused classes from the bundled CSS file, ensuring that only the classes being used are loaded by the client, resulting in significantly smaller bundle sizes. On top of that, every class that is bundled is reusable from anywhere that shares that stylesheet. The entire point of helper classes is that you're not having to reuse the same style properties, and therefore reducing the overhead of multiple classes sharing the same properties.

And you potentially avoid legal issues in future.

I'm not even going to bother asking what you mean by this, because this is obviously just a random thought you had that literally has no legs to stand on.

This is just such a poo, lazy, and elitist counter-argument to using a framework that genuinely solves a real-world problem for a lot of developers.

Thread Thread
 
thomasbnt profile image
Thomas Bnt

Bootstrap IS like Bulma, Tailwind isn't. So comparing it with Bulma is pretty much the same thing.

But don't write what I didn't write, in no case did I compare Bootstrap and TailwindCSS. And why always compare 'tools'?

Thread Thread
 
lukeshiru profile image
Luke Shiru

I just said:

A pretty common mistake is to glance over Tailwind and assume it is "like Bootstrap"

Which I meant like:

A pretty common mistake is to glance over Tailwind and assume it is a [component CSS framework].

That's why I used ". You can put "Boostrap", "Bulma", "Ant Design" and many others there. Used "Bootstrap" because is the most common one. And you said:

The team is using Bulma (same as Tailwind)

And it isn't the same as Tailwind, hence my reply 😅 ... I'm glad you're taking a look at the other comments and seeing some of the benefits. I really recommend you try it in a project so you can get why some many people like it so much ^_^

Thread Thread
 
thomasbnt profile image
Thomas Bnt

No, but it's always good to be curious and see how the tools are made.

And my comment can be confusing. I don't especially like Bulma because it adds things that, for me, are superfluous. And I greatly prefer to do it by hand.

And yeah I figured Bulma and TailwindCSS are pretty much the same content... but from what I see, this is not the case.

I just looked at the TailwindCSS site again, maybe I'll do something with it to see if I like it ! 🚀

Collapse
 
huzaifams profile image
HuzaifaMS

I agree with you.

I used to use tailwind a lot but my mind changed after reading articles from Jason knight. I started learning css from tailwind but kept coming across roadblocks and having to use custom css a lot to get things working the way I wanted them.

After seeing how html and css are actually better and really all you need for most of front end development. I stopped using tailwindcss.

Mainly because it didn't make sense to me to put styling info inside of html itself. It was much more cleaner to seperate the styling from the content and structure.

I also learned that all those class names bloated the ht l for user agents who had no need for styling.

Honestly seeing how badly websites with frontend frameworks and css frameworks load on a slow 3g connection goes to show how bad the products were and how little consideration was given to performance as a default. You'd have to spend exponential amount of time to reduce page transfer sizes to kbs instead of mbs compared to properly using
Html
Css
Js
For what they each were meant to be used for.

Sorry for the ranting. Props for the article.

Collapse
 
danwalsh profile image
Dan Walsh

Scoured the comments and can’t see anyone linking it, so I’ll pop it on here: In Defense of Utility-First CSS.

Great article well worth the read. Specifically, there’s a great paragraph around the “dogmatic” adoption of “separation of concerns”, rather than viewing your HTML and CSS as a “which depends on which” relationship. Really interesting stuff.

Happy to stick with my TailwindCSS scalable, maintainable and WCAG 2.1 AA complaint projects. Each to their own I guess! 😊

Collapse
 
rillus profile image
Riley

There's some great discussion here in the comments, and perhaps some of my contribution will have been covered, but I'd like to talk a little about my experience of both Tailwind and non-tailwind projects.

Tailwind serves a purpose, and it's good at what it does. It's not my first choice of framework for CSS, because I have extensive CSS experience and Tailwind is relatively new to the party, so if I'm working on a project with Tailwind I need to adapt my style slightly.

As an example: late last year I worked on a new project for a startup, and they'd chosen to use Tailwind. Their reason for doing so was simple and practical: their CTO was more of a backend developer than a frontender, and he hadn't done much CSS in his career. Tailwind removes issues of inheritance and cascading to a good degree, so he knew he could apply a class and style as he wanted without having to dive into CSS too much and learn about all it's intricacies.

I think Tailwind is great for prototyping quickly, and we got good traction early by using it, but as certain patterns emerged from the code, and as the codebase swelled, I found myself wanting (and perhaps even needing) a more structured approach. In order to reuse lengthy groups of classes, I converted some of these into CSS Components. This had the useful side-effect of reducing the size of the HTML, adding context to some elements and allowing us to update the style across multiple pages if needed. As a simple example, rather than having the heading definitions sprinkled throughout the project:

<h2 class="font-semibold text-xl text-gray-800 leading-tight">
Enter fullscreen mode Exit fullscreen mode

Using Tailwind's @apply syntax, this becomes

<h2 class="Heading2">
...
.Heading2 {
  @apply font-semibold text-xl text-gray-800 leading-tight;
}
Enter fullscreen mode Exit fullscreen mode

While adding a class looks like more code, as soon as you have multiple identical h2 tags on different pages you soon start to benefit.

This problem could be mitigated with components in your favourite JS framework, but you may decide you don't need a component just for a header (until that header has more functionality you want to control), or you may decide that for simplicity the overhead of multiple identical headings using Tailwind is fine - that's cool. There's no wrong answers here.

Tailwind can be a great asset, but it can also be misused. I recently inherited some React code for a new project, and one page I need to work on is a contact form. The code starts like this:

<div className="relative bg-white">
      <div className="absolute inset-0">
        <div className="absolute inset-y-0 left-0 w-1/2" />
      </div>
      <div className="relative mx-auto max-w-7xl lg:grid lg:grid-cols-5">
        <div className="py-16 px-4 sm:px-6 lg:col-span-2 lg:px-8 lg:py-24 xl:pr-12">
          <div className="mx-auto max-w-lg">
            <h2 className="text-2xl font-extrabold tracking-tight text-brm-grey-900 sm:text-3xl">
              Get in touch
Enter fullscreen mode Exit fullscreen mode

I can read this and make sense of it, and I can run the project and see what's happening here, but it's not very pretty (to my eyes) and probably needs to be refactored into sub-components so I can reuse these styles on other forms I'll be building soon.

This code would also benefit from using semantic tags for context and SEO, but these are issues with this implementation, and not a problem with Tailwind itself.

The OP mentioned that Tailwind could be good for a hobby project. This is unnecessarily harsh, as Tailwind can (can does) work well on enterprise projects, but if you opt for it will depend on your team's strengths, your tech stack as well as your own personal preference.

So, don't "say no to Tailwind", say instead "what problem does Tailwind try to solve? And will it help my team deliver this project?"

Collapse
 
thethirdrace profile image
TheThirdRace • Edited on

While I'm not a big fan of Tailwind, this article is all kind of wrongs...

Here's how I would have written the article instead.

Embrace the separation of concerns

Inline CSS, and the way tools like Tailwind are mainly used, may help you develop your project faster, but there are costs...

HTML shouldn't cross in CSS or JS territories

HTML should only contain content, hierarchy, structure and the necessary hooks to add interactivity and styling.

There's a huge advantage to separate the code from the hooks: reusability.

CSS example

CSS Zen Garden is an awesome example of this principle.

In CSS Zen Garden, you can completely transform the whole website by simply providing a new stylesheet. No code change whatsoever is needed beside including the new stylesheet.

JS example

With the modern "component first" approach, you already separate the structure from the actual interactivy code.

Let's say you have a Button component in React that goes like this:

export const Button = ({children, onClick}) => {
    return <button onClick={onClick}>{children}</button>
}
Enter fullscreen mode Exit fullscreen mode

As you'll immediately see, the onClick is passed as a prop.

But why? Well, because of reusability of course!

If you inline the code of the onClick directly in the Button component, that Button will only ever do that one trick. By passing the interactivity code through the prop, you can make the Button do pretty much anything. 1 vs infinite possibilities, the choice isn't hard to make...

Basically, you hooked the interactivity code in the Button structure, but you kept the actual code separated.

The advantages are obvious to proceed this way, I don't think I need to explain any longer than that...

Conclusion

The real choice here is: do you need the reusability?

If you want to reuse components between projects, you need them to be agnostic in styles and interactivity code. This could help you scale multiple projects much faster and keep bugs minimal since everything can be fixed at only 1 place. There are huge scaling advantage going this way.

If you don't need to reuse components between projects, then it's a matter of preference between inlining or not.

Inlining the styles will definitely speed up the project's development, less abstraction equals less code, less bugs, less maintenance, etc.

Personally, the reusability is the deal breaker for me. If I always need to start from scratch, then I feel I didn't do my job right. I understand it might be "right" for a project given the time tables and goals, but at that point I wouldn't be the "right" person for the job. But that's just me, different people have different goals, let's leave it at that... 😅

Collapse
 
decker67 profile image
decker

Totally agree.
Writing "bg-slate-100 rounded-xl p-8 dark:bg-slate-800" instead of "testimonials" more than once is hard to understand, read and maintain, so why should we do so?
Because we don't know CSS.

Collapse
 
lukeshiru profile image
Luke Shiru

so why should we do so?

Because WebDevs use tools to create components, so we don't need a "testimonials" class name, because we have a Testimonials component. So the actual comparison looks more like this:

const Testimonials = props => (
    <section
        className="
            bg-slate-100
            rounded-xl
            p-8
            dark:bg-slate-800
        "
        {...props}
    />
);
Enter fullscreen mode Exit fullscreen mode

Versus this:

/* Testimonials.module.css */
.Testimonials {
    background-color: var(--slate-100);
    border-radius: var(--border-radius-xl);
    padding: var(--space-8);
}

@media (prefers-color-scheme: dark) {
    .Testimonials {
        background-color: var(--slate-800);
    }
}
Enter fullscreen mode Exit fullscreen mode

And then the JSX:

// Testimonials.jsx
import styles from "./Testimonials.module.css";

const Testimonials = props => (
    <section className={styles.Testimonials} {...props} />
);
Enter fullscreen mode Exit fullscreen mode

So there isn't any real value in creating that .Testimonials class name because when you use the component, you use the JSX, not the CSS.

Collapse
 
decker67 profile image
decker

Yes writing components is the best thing you can do to avoid repeating those ugly class bullshit. But why than using them at all. With SFC in Vue you have a local environment to style your component with real classes that contains real CSS, you should learn at all.
So no need to use Tailwind to use another indirection and not understanding CSS.

Collapse
 
brianmcbride profile image
Brian McBride

Ok. I found one example of Tailwind that I am sort of ok with.

First, the whole @apply thing to name a class is ill advised by Tailwind? I see a lot of component libs using it.

But material-tailwind.com/ took an approach to combine the tailwind strings as JS. No idea if it still compiles to small css files. But for a lot of short-hand css, it isn't bad. Sure, it is super easy to add padding in css. I'll admit that py-2 with the 2 a multiplier of my base spacing could be easier for a team to remember.

But the instant the HTML gets overloaded with all this, it just becomes noise.

Collapse
 
tbroyer profile image
Thomas Broyer

I have visceral aversion for tailwind and other " utility css" frameworks, but maybe when used with component frameworks like React it might be worth it: with small enough components you care much less about "separation of concerns" between markup, styling and behavior (you keep them all in a single file, or possibly two closely related files) and then maybe in this situation those tools shine. But that'd be the only situation I'd accept using them. I'm traumatized enough by Bootstrap already.

Collapse
 
lukeshiru profile image
Luke Shiru

I'm traumatized enough by Bootstrap already.

You have to consider that Bootstrap is not the same. Bootstrap provides components (similar to Bulma, Foundation, Ant and others) while Tailwind is an utility/atomic CSS solution.

As you said, it doesn't make much sense to use it on its own (it would be crazy to use Tailwind in vanilla HTML), the idea of the atomic/utility CSS solutions is that they go very well with componen libraries and frameworks (basically what we all are using nowadays), such as React, Vue, Angular and so on. This is manily because the component abstraction is mainly made at the JS level, so CSS is just there to style said components, not to define them.

If you have a side project with any of those libraries or frameworks, give Tailwind a try. I promise you'll not regret it.

Collapse
 
timexpeachtree profile image
Timex Peachtree

Yes there are simpler lightweight frameworks like PureCss which are bit simpler and provide bare minimum for websites which need to be blazingly fast and work under non-optimal Low-speed networks.

It can also be used as base along with only required components from other frameworks, eg. Bootstrap Modal, etc.

Very good article, appreciate it.

Collapse
 
lukeshiru profile image
Luke Shiru

Pure CSS and Tailwind are completely different (one is utility CSS and the other component CSS). Tailwind can be as lightweight or more than Pure because it only ships the CSS that you actually used. Nothing more, nothing less.

Collapse
 
brianmcbride profile image
Brian McBride

Tailwind seems easy at first. Then you end up with a crazy HTML with so much class markup it is hard to figure out.

So then you start composing your tailwind so that you can apply a style easier. At that point, you might as well use CSS?

Collapse
 
sebastianinman profile image
Sebastian Inman • Edited on

This is a bad take.

First off, CSS libraries like Tailwind have absolutely nothing to do with the semantic markup of the HTML content, so bringing that up is a totally moot point.

As far as "better SEO" and performance is concerned, Tailwind, out of the box, removes any unused classes from the bundled CSS file, ensuring that only the classes being used are loaded by the client, resulting in significantly smaller bundle sizes. On top of that, every class that is bundled is reusable from anywhere that shares that stylesheet. The entire point of helper classes is that you're not having to reuse the same style properties, and therefore reducing the overhead of multiple classes sharing the same properties.

And you potentially avoid legal issues in future.

I'm not even going to bother asking what you mean by this, because this is obviously just a random thought you had that literally has no legs to stand on.

This is just such a poor, lazy, and elitist counter-argument to using a framework that genuinely solves a real-world problem for a lot of developers.

Collapse
 
davidrock profile image
David Rock

You are using the wrong reasons to do not like a bunch of classes in a HTML element. Tailwind is about using composables classes that do exactly what the class name
means. And you really can use @apply to stick together those classes in just one classe name in order to make html cleaner. This is future, this is fast e highly customisable css. Tailwind has a lot of others features, you probably won't have a smaller css bundle than the tailwind's purge system. I don't really know what you mean with "avoid legal problems in the future".
Your article doesn't have strong reasons why people should stop using it besides a pure opinion based. You should show numbers, bundle size, benchmarking or at least a real scenario where tailwind ruined the project. Without that your article won't convince much people, only the ones whose are looking for a reason to do not learn tailwind.

Collapse
 
neoprint3d profile image
Drew Ronsman

This is hilarious to read. Just use what you want that is sensible and works best for your needs. Btw I use tailwind go tailwind

Collapse
 
danielsmith profile image
Daniel Smith

this is ridiculous. The overall attitude is to go "bare metal" with each aspect of development. I suppose that is fine if you have all the time in the world, and want to be completely Artisan about it. Do you grind your coffee beans with a Mortar and Pestle too?

it's like saying "dont use Laravel, stick to bare PHP". Or the same idea for Angular, React, Vue, or Svelte.

it's like saying "dont use an ORM, stick to MySQL direct"

you say mastering CSS can't be hard. That may be true. But, let's see, what else have we got going on in the project? Some HTML, of course. Lots of JavaScript, perhaps with some libraries or frameworks.. oh, and what's this over here? Some WebSockets? ok, cool. Oh, and a chrome extension, and perhaps the Push Notifications API? Nice! And hey dont forget about Local Storage. Still with me? Did you switch over to ViteJS to get away from the complexity of WebPack? I did! Do I need to mention WebGL? You against using Three.js for that?

Oh, and we're not done yet! There's some node.js.. how about we just use that raw? Do you object to people using Express? And we're using MongoDB as a store, so should we do that raw? You object to using Mongoose? I could go on. citing examples from Networking, Security, AWS, DevOps, and so on.

Almost everything I mentioned has come up for me this year. I dont have the luxury of hanging out in a particular silo, such as pure css. TailwindCSS is a solid means of getting a great result. And yes, I'm talking about real enterprise paying stuff...

If you are specializing in some narrow aspect of web dev, and you wish to go bare metal, more power to you. But dont expect it to fly with those who have projects that are literally Rube Goldberg machines with lots of moving parts. we have deadlines, and we need to get things done. TailwindCSS is wonderful for what it does.

Collapse
 
matiaslauriti profile image
Matias Hernan Lauriti • Edited on

The issue with this post is that it is more a rant than a "don't use tailwind because is bad for entrerprise and here are the facts".

You did not show/share facts at all, everything was subjective, and you also mixed HTML with CSS (HTML semantis has nothing to do with CSS).

This is another post ranting why a dev does not like a TOOL, than a post showing why (relative to the author) is a bad tool...

I would say try to write it again, but have facts. If you don't, then you did not understand the tool.

Collapse
 
pengeszikra profile image
Peter Vivo

Maybe you can use @apply for solve your antipathy of Tailwind.