DEV Community

Cover image for Hate on Tailwind... I have seen that before!

Hate on Tailwind... I have seen that before!

Nícolas Gabriel on November 04, 2023

In 2013, a company called Facebook introduced a framework called "React," which allowed developers to blend their JavaScript logic with their HTML ...
Collapse
 
sultan99 profile image
Sultan

Actually, Tailwind is the next evolution in styling. Before CSS, we used to style elements like this:

<p>
  <font color="red" face="Verdana, Geneva, sans-serif" size="+1">
    <b>Your formatted text goes here</b>
  </font>
</p>

Enter fullscreen mode Exit fullscreen mode

However, this approach was deprecated with the introduction of CSS. With Tailwind, we are revisiting the concept, but instead of using attributes, we now put all styles in a className with shortened classes. This madness pushed me to come up with a new idea: importing styled React components from a CSS file, where all style manipulation can be done through component properties:

import { Title } from './styles.scss'
// crazy part, importing 👆 component from styles

<Title color="tomato" size="small">
  Hello world!
</Title>

Enter fullscreen mode Exit fullscreen mode

Where style.scss file looks like this:

/**
  @tag: h1
  @component: Title
  size: small | medium | large
  color: #38383d --color
*/
.title {
  --color: #38383d;
  color: var(--color);
  font-size: 18px;

  &.small {
    font-size: 14px;
    margin: 2px 0;
  }
  &.medium {
    font-size: 18px;
    margin: 4px 0;
  }
  &.large {
    font-size: 20px;
    margin: 6px 0;
  }
}

Enter fullscreen mode Exit fullscreen mode

For more information, please check out the demo and repository:

Online demo
GitHub repo

Collapse
 
nickgabe profile image
Nícolas Gabriel

That's a super interesting idea! Loved the concept!

Collapse
 
joshuaamaju profile image
Joshua Amaju

That tell's me all I need to know about your position on tech choices 😂

Collapse
 
syeo66 profile image
Red Ochsenbein (he/him)

You might want to take a look at PandaCSS for a similar but framework agnostic approach.

Collapse
 
sultan99 profile image
Sultan

There's nothing particularly unique about Panda CSS in terms of its idea or approach. Many CSS-in-JS libraries offer similar ways of styling.

Thread Thread
 
syeo66 profile image
Red Ochsenbein (he/him)

Tailwind isn't a new idea either.

Thread Thread
 
sultan99 profile image
Sultan

Yeah, but Tailwind made this approach popular, just as styled-components popularized CSS-in-JS. Other CSS-in-JS libraries introduced additional features, such as build-time extraction and shortened CSS classes, but in general, it is the styled component approach.

What I know is that there are several ways to style components:

  • CSS module
  • CSS in JS (styled-component way)
  • Tailwind
  • Inline styles
  • Stylin with mapping style annotations

P.S.: If I had to choose between Tailwind and PandaCSS, I would pick PandaCSS.

Collapse
 
moopet profile image
Ben Sinclair

Who knows, maybe in 10 years, Tailwind will also become one of the most famous ways to write CSS

I think we're already there, unfortunately. In my experience, Tailwind is overwhelmingly loved by front-end developers.

Collapse
 
siy profile image
Sergiy Yevtushenko

There are reasons for hate. Take a look at this article. I'd suggest read other articles from this author too. It's not a plain dislike or taste based hate. It's well grounded position. But, well, language might be somewhat offensive to some framework lovers.

Collapse
 
adaptive-shield-matrix profile image
Adaptive Shield Matrix • Edited

The biggest / most fair critique against tailwind I heard against is

  • it makes things hard to read, by/if using multiple lines of tailwind classes
  • using many divs in sequence - that makes it hard to distinguish between them
  • you have to memorize that all the shortcuts mean, ex. p-1 text-sm

Here is an Article with said critique in more detail
nuejs.org/blog/tailwind-vs-semanti...

I feel like the critique comes most often from designers, who translate figma design into html/css and have less knowledge on how to write idiomatic react code.

First 2 problems are solved if

My biggest grip with react + tailwind is, that I wish I could shorten className to just c or class, because it is such a long word to type out and it takes to much screen / line space.

Collapse
 
moopet profile image
Ben Sinclair

That's a good linked article.

Collapse
 
maxart2501 profile image
Massimo Artizzu

I feel like the critique comes most often from designers

The set of designers that do HTML/CSS development is definitely non-empty, but it's not the norm IME. Figma has also a decent Tailwind plugin for the matter, so they wouldn't even sweat to translate their design into Tailwind mashups.

First 2 problems are solved if

  • extracting said divs into separate components
  • using libraries like
    • tailwind merge - github.com/dcastil/tailwind-merge
    • and cva - github.com/joe-bell/cva
    • to merge and group class names

I fail to see how tailwind-merge could improve readability, while the others basically throw one of the main advantages of Tailwind out of the window: eliminating the necessity of naming things.

My biggest grip with react + tailwind is, that I wish I could shorten className to just c or class, because it is such a long word to type out and it takes to much screen / line space.

I personally never write className in full, because the IDE suggests it right away when I type just c, but I'm amazed to see that you consider className "too long" while the value could be something like bg-white border-slate-100 transition-all duration-500 demo-dark:bg-slate-800 transition-all duration-500 demo-dark:border-slate-500 border-b rounded-t-xl p-4 pb-6 sm:p-10 sm:pb-8 lg:p-6 xl:p-10 xl:pb-8 space-y-6 sm:space-y-8 lg:space-y-6 xl:space-y-8.

Collapse
 
adaptive-shield-matrix profile image
Adaptive Shield Matrix • Edited

while the value could be something like "long lines of tailwind"

I group similar tailwind classes together

Example:

export function CardWrapper({ children, className }: { children: React.ReactNode; className?: string }) {
  return (
    <div
      className={cn(
        "rounded-lg  shadow-lg", // card border + shadows
        "p-4 lg:p-8", // padding
        "bg-white dark:bg-gray-900", // bg
        className,
      )}
    >
      {children}
    </div>
  )
}
Enter fullscreen mode Exit fullscreen mode

somewhere in ui / utils

function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}
Enter fullscreen mode Exit fullscreen mode

In the long lines of tailwind classes you provide

  • why do you not group tailwind classes (like in the example above)?
  • why do you not separate it into a separate component (like in the example above)?

Separating into function components like in the example

  • Is the example above hard to read?
  • Will it be if you add some more lines of tailwind classes in the same way?
  • I can give an example with even more tailwind classes following same pattern and I find it is very readable and maintainable for myself.
  • The only downside I see is you have to write many separate function components and naming them (vs similar how you have to define/name things for in css).
Thread Thread
 
maxart2501 profile image
Massimo Artizzu
  • why do you not group tailwind classes (like in the example above)?

Because it's not straight from the source - it's the output, taken directly from Tailwind's homepage. If I have to debug a problem, that's something the dev tools presents me.

  • why do you not separate it into a separate component (like in the example above)?

Common answer: because I don't want to name things.

  • Is the example above hard to read?

Definitely harder that reading plain CSS, yes.

Collapse
 
aquaductape profile image
Caleb Taylor

My biggest grip with react + tailwind is, that I wish I could shorten className to just c or class

There's solidjs, lit or preact that uses just class attribute

Collapse
 
pcesarteixeira profile image
Paulo Teixeira • Edited

I understand the reasons, but I don't like it. I know that evolution is necessary, but I also see front-end as an amusement park without supervisors, there are good ideas emerging wildly, and just because it seems cool to me doesn't mean I'll go into production and have to deal with it in 5 years.

Lots of new technologies wanting to solve problems that aren't even problems yet, that will probably cause problems.

Collapse
 
nickgabe profile image
Nícolas Gabriel

interesting point of view 🤔
we usually think about the now and not about the distant future, but that is something we should keep in mind as well, so, fair judgement I would say

Collapse
 
forestdev profile image
Dominykas Bartkus

In the end, it is your responsibility to choose what works for you. It’s always a the matter of: “can I afford this abstraction/solution or should I choose battle tested tech?”

It’s the matter of what you think will be most stable and scalable for you software.

For instance, I regret choosing prisma as an ORM. It’s great for basic projects, but for larger projects that you need more control over prisma is awful outside of it’s schema and migration tool.

Is it bad on its own? No, just not perfect for what we’re building for multiple query related reasons.

Love its typings though.

Anyway, I’m all for new tech. Just make your judgment whether you should or shouldn’t use it. Don’t trust the hype.

But even with all the hype around tailwind, I found it useful. I don’t care about css much. Just want things to work, and tailwind provides me that out of the box without having to care about building my own set of standards. And 90% of the time it works 100% of the time.

Collapse
 
lixeletto profile image
Camilo Micheletto

Separation of concerns is just another opinion from what software could be and it's a lazy way to measure if a language can or cannot provide what your business needs in CSS architecture.

Tailwind provides an easy interface to CSS by dropping most of its funcionalities and abstracting it's units and APIs. This is not wrong, not good for everything and hard to measure in an industry that sees CSS architecture as a liability. When we talk about CSS we can be sentimental about it, we can talk about perceived performance in how fast we code or how we feel when coding, and care less about how it makes sense in a business model and if it truly provides an API that does not rely on template and are tightly copled to an ecosystem providing functionality.

Today tailwind future is bright and we can afford not to think about CSS at all, and abstracting even further regarding of its limitations, and it's ok, even if it does not makes sense > every time < business wise as the community makes it.

As you said the wheels always turns, it's good to see some fresheness, but I wish the discussion regarding CSS technology were deeper than the surrounding Tailwind are. Knowing it's limitations is also a power that makes you use it wisely.

Collapse
 
maxart2501 profile image
Massimo Artizzu

we can afford not to think about CSS at all

I hope this is just an unfortunate way you expressed yourself, because that would be a terrible approach. Tailwind does not save you to learn and think of CSS.

Collapse
 
lixeletto profile image
Camilo Micheletto

Yes It does. Don't get me wrong, theorically I'm with you. In practice people could care less what Tailwind outputs as CSS as long as it works layout-wise - and the industry doesn't seem to care as well, CSS architecture is hard to grasp, to mantain and to enforce certain patterns.

So when I say

we can afford not to think about CSS at all

I'm saying that you can write the most verbose, repetitive, media-query full class based CSS and don't ever open the devTools again nor check the output code as long as layout works, relying only in template based reuse, JIT and compression in matters of performance, as if it were enough (it isn't).

Thread Thread
 
maxart2501 profile image
Massimo Artizzu

as long as layout works

And that's the point. Because almost nothing works on the first try, you'll eventually have to debug, and understand what's going on. And devtools presents you CSS, not Tailwind - which is not, and will arguably never be - a first class citizen.

I won't even mention that Tailwind's own documentation is full of references to the corresponding CSS properties and/or mechanics, so you have to know CSS to understand what Tailwind means.

What you're imaging - an abstraction layer that renders knowing what's under the hood completely optional - is a pipe dream that will eventually collide with reality (and in the case of Tailwind it fortunately happens very soon).

It's not something we haven't seen in the frontend community, mind you. Back in the day, there were jQuery developers who hardly knew anything about the DOM or even JavaScript. More recently, we have React developers who get lost outside of it. Accumulating knowledge debt isn't a route with a good outlook, although it seems sufficient in the short term.

Thread Thread
 
lixeletto profile image
Camilo Micheletto

I really hope you are right, because when there is an error with jQuery, it'll certainly break the application. CSS errors, verbosity or misconceptions are way more cheaper and overlooked, even if the layout breaks at some point. I had this problem working with CSS, SCSS and even Styled codebases, but with Tailwind is worse, not only because the thicker abstraction layer, but the community around it.

Collapse
 
latobibor profile image
András Tóth

The same idea is repeated with ORMs which in my opinion comes from a very greedy point of view: we don't have time to understand something in depth, we want it immediately.

This is not a bad thing, on its own, when you work on prototypes and do market-research and you try to land what exact features bring value to people.

But then, eventually, successful companies need to scale; they start serving more people, the amount of data grows very large under them and so on.

You can't afford not understanding how SQL works, how the specific database you use work. You would do tons of ineffective queries with an ORM that can be into 1 query 1 round-trip with a mid-level SQL knowledge.

Same is true with CSS: you can design a set of rules that are easy to change, but if you don't understand it, and with the magic framework for hiding it for you, you won't be able to achieve certain effects, you will struggle a lot with a design change, your code will be brittle and ineffective, because there were much simpler ways that even a mid-level CSS developer would have created for you.

Why I am angry with bootstrap and tailwind and the rest, that they are no longer sold as a great tool for rapid prototype; we are told that it is "evolution", it is the logic next step.

It is not! Neither are ORMs. You can't skip learning your craft. You will need it eventually.

Collapse
 
efpage profile image
Eckehard

Maybe we should look at the topic a little more generally...

HTML is not the first language to build User interfaces. If you write an application for windows, linux or apple, things are very similar. If you need an input field, you will define it in a similar manner you do in HTML. But in traditional applications, you do not have so much control over the appearance, in fact, most visual components are styled by the OS, not the application. This may limit the developer, but gives a better user experience. Companies like Apple have their Human Interface Guidelines to ensure a uniform user experice - something we would whish we had for web developers today.

HTML / CSS was initially not designed as a UI toolkit, it was designed to apply better styling to static documents. The more the web is used to build applications, the more the conceptual issuses of CSS/HTML will be visible. The web is evolving from a presentation platform to an application platform. Any modern CSS toolkit should support this evolution, so future will show, if tailywind does the job.

Collapse
 
latobibor profile image
András Tóth

The false dichotomy of the day is this:

// whoa, so little!
<div class="px-0 pt-1 text-sm" />
Enter fullscreen mode Exit fullscreen mode

vs.

/* Ew, too long */
.my-component {
  padding: 0.25rem 0 0 0;
  font-size: 0.75rem;
  line-height: 1rem;
}
Enter fullscreen mode Exit fullscreen mode

For a more eloquent great case against using utility classes please read this: every-layout.dev/rudiments/global-...

Now my short opinion. Locally styling each and every component is bad CSS practice. You should have a lean vocabulary of well-defined bigger components and shapes. You see, CSS is an exception-based language: you create a set of general rules, and then only write further ones, when you have to differ from those.

Tailwind on the other hand, went full in with local styling.

When you have globally set general rules, you will have less changes required to change the appearance of the page. If anyone here remember CSS Zen garden, it was possible only because the classes on the items were semantic. CSS Zen garden would have never been possible using the tailwind approach.

Generating another style would instead mean to rewrite each and every component. Let's say: screen sizes grew and we can afford thicker margins? With tailwind approach now you have to go into each items and change those values. Because you have eliminated general rules from the equation, now everything is an exception.

This line: <div class="px-0 pt-1 text-sm" /> means that you want an average <div> except that it has no horizontal padding, it has 1 amount of top padding and it also has a special small set of font.

If you are lucky enough someone in the team will have a brain to move it into "presentational" React component, that does nothing just the same thing class="something" would do.

Collapse
 
pengeszikra profile image
Peter Vivo • Edited

Imho Tailwind greatest strength is eliminate the abstraction layer between layout of HTML and CSS. Before Tailwind I need to be use a verbose and class link between HTML DOM and CSS, with boring name giving process. With Tailwind mandatory layout information is stay here where it is belong.

export default component$(({contentList}) => { 
  return (
    <main class="grid place-items-center min-h-screen">
      <article class="grid gap-2 w-2/3">
         { contentList.map(({content, id, user}) => 
            <Paragraph id={id} user={user} content={content} />
         )}
      </article>
    </main>
  )
};
Enter fullscreen mode Exit fullscreen mode

In this example easy to understand which layut setup are we build. Does not need to futher explanation.

The JSX format MVC concept is really simple: The return object is the View, the props or useContext is the Model, and the hooks is the Controller.

Collapse
 
maxart2501 profile image
Massimo Artizzu

You're forced to name things only because of the limitations of your framework of choice. How about this:

main {
  display: grid;
  place-items: center;
  min-height: 100vh;
}
article {
  display: grid;
  gap: 0.5rem;
  width: calc(100% * 2 / 3);
}
Enter fullscreen mode Exit fullscreen mode

If you have a truly encapsulated stylesheet - even emulated - you could do this.

Collapse
 
pengeszikra profile image
Peter Vivo

You are right this is the CSS solution but the problem is the selector: main and article which is to global and it is affect all main and article. But the tailwind does not need to create instance name, and recreacte DOM selector in CSS side.

Thread Thread
 
maxart2501 profile image
Massimo Artizzu

I mentioned style encapsulation for a reason: those selectors would have a local scope only.

This has been possible for a while, even natively.

Thread Thread
 
pengeszikra profile image
Peter Vivo

My example does not framework dependent, that DOM part can be written in plain HTML too.

Thread Thread
 
maxart2501 profile image
Massimo Artizzu

I never mentioned any framework either. I said it's possible to do that natively.

Thread Thread
 
pengeszikra profile image
Peter Vivo • Edited

Sorry I missunderstand you, In my point of view simple:

<foo class="layout by tw">
  <content />
  <content />
  <section class="another layout by tw">
     <input />
     <button />
  </section>
</foo>
Enter fullscreen mode Exit fullscreen mode

Is much easier mental model than

<foo class="layoutCSSClassName">
  <content />
  <content />
  <section class="anotherLayoutCSSClassName">
     <input />
     <button />
  </section>
</foo>
Enter fullscreen mode Exit fullscreen mode
.layoutCSSClassName {
 //
}

.anotherLayoutCSSClassName {
  //
}

Enter fullscreen mode Exit fullscreen mode

Because In first case you can immediatly know everything about your layout conception, elements and layouts directive with a well .

Thread Thread
 
maxart2501 profile image
Massimo Artizzu

Why should you know what's the layout from the markup? The markup is for the content.

What I suggest is something like this:

<foo>
  ...
</foo>
Enter fullscreen mode Exit fullscreen mode

with a corresponding CSS:

foo {
  /* layout styles */
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
gabonezio profile image
Gabriel Onezio Ferreira

10 years? I believe that as the technological evolution is exponential, tailwind will evolve in less than 2 years for this to become an interesting factor!
Image description

v1.tailwindcss.com/docs/upcoming-c...
On the official Tailwind CSS website, there is a section called Upcoming Changes, which shows the updates and deprecations coming in the future and how to prepare for them. For example, they plan to remove the deprecated gap classes, change the purge mode for layers by default, and add default line heights to the font size classes. These changes are intended to simplify and improve the use of Tailwind CSS.

Collapse
 
skttl profile image
Søren Kottal

Tailwind is at version 3.3, and the changes you mention has long been done.

Collapse
 
learncodeprofessor profile image
LearnCodeProfessor

Great post!

Collapse
 
zkriguer profile image
zKriguer

Thats a good approach, thanks for sharing your experience with both ways to do CSS.

Collapse
 
fabiovaz profile image
Fabio Vaz

I love work with tailwind, so much fast.

I would like to just add one fix to your css “px-0 pt-1 text-sm”
In css its was something like
padding: .25rem 0 0;
font-size: .75rem

This just 2 lines will be the something

Collapse
 
nickgabe profile image
Nícolas Gabriel

Tailwind sets the properties one by one, not the shorthand afaik
tailwindcss.com/docs/padding

And the text-sm also adds the line-height
tailwindcss.com/docs/font-size

Collapse
 
fabiovaz profile image
Fabio Vaz

Yes I agree. But to make a comparison whether the tailwind is verbose or not, we also need to use a correct CSS structure, or it would be like me demanding that the tailwind be set to "pl-0 pr-0 pt-1 pb-0". I believe that the text is not how tailwind renders it, but rather a comparison between tailwind and css in terms of verbosity.

In relation to the line height, in the tailwind it also sets the arrow to make it easier to change the "leading". But the default line-height is 1.2, without being in rem. It also becomes proportional to the font-size.

Thread Thread
 
nickgabe profile image
Nícolas Gabriel

Oh ok ok, I got your point now. Makes sense, I made a comparison against its own "production" code, but you're correct, we would not write it that way as if we were writing CSS directly.
Thanks for clarifying

Collapse
 
dsaga profile image
Dusan Petkovic

I wonder what is the best practice in Tailwind for grouping styles, in normal css you can do that with classes, and then create a special class to indicate a specific button style.

What I don't like is having to copy and paste the same classes over and over... I've used the @apply directive but not sure if its the best practice..

Collapse
 
latobibor profile image
András Tóth

That's where the design mistake shows. In a well-architected CSS page, you set sensible defaults for main elements. You look at your HTML tags, you create sane defaults for them that already gets you 80% there. Then you create special HTML classes that will represent your main layout components: is it a main panel, is this a header, is this a label? And so on. You are 95% there.

Finally you look at the components which need adjustment and you define those rules. This is a top-down approach, requiring knowledge of CSS and HTML, also you should have a lot of certainty of what kind of application you want to build.

Tailwind's approach is to work in isolation, bottom-up: you get a design, you add HTML tags until it matches closely what they gave you and you move on. You don't discuss decisions, you don't factor in future changes, you go and get productive now. Perfect for companies where people want to work hard, but smart, scaling or future-proof are not requirements.

In my opinion, if you wish to write code for long-term, you have to understand good CSS architecture.

If you want a band-aid, you can also make presentational components, that now nothing about anything, they just accept children and that's it.

export function TheSameComponentUsedEverwhere({ children }: props) {
  return <div className="bg-white border-slate-100 transition-all duration-500 demo-dark:bg-slate-800 transition-all duration-500 demo-dark:border-slate-500 border-b rounded-t-xl p-4 pb-6 sm:p-10 sm:pb-8 lg:p-6 xl:p-10 xl:pb-8 space-y-6 sm:space-y-8 lg:space-y-6 xl:space-y-8">{children}</div>
}
Enter fullscreen mode Exit fullscreen mode

Which you can use as:

function MyComponent(props) {
   const { posts } = useExternalStore(); 
   return <TheSameComponentUsedEverywhere>
    {posts.map(({url, title}, index) => (<a href={url} key={index + '_' + title}>{title}</a>)}
   </TheSameComponentUsedEverywhere>
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
dsaga profile image
Dusan Petkovic

Its certainly the opposite of how I am normally used to write CSS, but maybe it plays well with the component based architecture...

Collapse
 
maxart2501 profile image
Massimo Artizzu

It is not according to Adam Wathan himself.

Collapse
 
dsaga profile image
Dusan Petkovic

So the @apply directive is the best way to group?

Thread Thread
 
maxart2501 profile image
Massimo Artizzu

No, I mean Wathan discourages the use of @apply.
He provided it to ease the adoption of Tailwind, but he personally just chugs classes into the markup.

Collapse
 
victordolzan profile image
Victor Dolsan

Nice post! I think Tailwind will become the standard way in a very short time

Collapse
 
maxart2501 profile image
Massimo Artizzu

I don't think I'll ever stop thinking Tailwind is a footgun, generally speaking.

Other than polluting the markup, my main concern is that it's another cognitive layer on top of CSS. Meaning you have to learn Tailwind's "syntax" in order to use it. At that point, I'd be happy using CSS straight away.

Not to mention that Tailwind's syntax for some more-than-dead-simple cases (like a calc, a custom property or simply targetting descendants) is clunky at best:

<div class="w-[calc(50%-80px)] text-[color:var(--text-color)] [&>*]:p-4">
Enter fullscreen mode Exit fullscreen mode

I understand the nicety to use utility classes, but definitely not to make a mess out of your markup - that is now more like a <div>-soup:

<div class="relative pt-10 xl:pt-0 mt-10 xl:mt-2">
  <div class="max-w-7xl mx-auto px-4 sm:px-6 md:px-8 lg:grid lg:grid-cols-12 lg:gap-8">
    <div class="lg:col-span-5 xl:col-span-6 flex flex-col">
      <div class="relative xl:mt-18">
        <div class="mt-6 sm:mt-10 relative z-10 rounded-xl shadow-xl">
          <div class="bg-white border-slate-100 transition-all duration-500 demo-dark:bg-slate-800 transition-all duration-500 demo-dark:border-slate-500 border-b rounded-t-xl p-4 pb-6 sm:p-10 sm:pb-8 lg:p-6 xl:p-10 xl:pb-8 space-y-6 sm:space-y-8 lg:space-y-6 xl:space-y-8">
            <div class="space-y-2">
              <div class="relative">
                <div class="ring-cyan-500 transition-all duration-500 demo-dark:ring-cyan-400 ring-2 absolute left-1/2 top-1/2 w-4 h-4 -mt-2 -ml-2 flex items-center justify-center bg-white rounded-full shadow">
                  <div class="w-1.5 h-1.5 bg-cyan-500 transition-all duration-500 demo-dark:bg-cyan-400 rounded-full ring-1 ring-inset ring-slate-900/5">
Enter fullscreen mode Exit fullscreen mode

This is taken straight from Tailwind's homepage, by the way. When you forfeit control of the meaning of your DOM, this is usually the result.

The main alleged advantages of Tailwind all seem very weak to me:

  • the size of the generated CSS is much smaller - but CSS has hardly ever been a problem for size and CPU load;
  • HTML can be well compressed with gzip and others - but CSS is compressed even better and it's usually cached, while HTML is not;
  • it saves you from the burden of "naming things" - but naming is a developer skill, and keeps track of why you're doing what you're doing;
  • it lets you forget about the cascade - but the problem with the cascade is when it becomes too big to be easily handled, while there are many other native solutions for that (style encapsulation, style scoping, cascade layers).

Yes, the last point means that you need to learn and understand some advanced mechanics of CSS that need time and effort to be fully internalized. Tailwind wins when the team has developers with less experience in CSS, because it's an easy-enough solution for all. But those less-experienced devs will also have the worst time when it comes to maintain their own code.

Collapse
 
artxe2 profile image
Yeom suyun

I don't like Tailwind very much, but its growth is overwhelming.

Collapse
 
maxart2501 profile image
Massimo Artizzu

Is it?

Since the last year:

  • "not interested" remained stable (25% to 24.9%);
  • "interested" fell quite some (25% to 22.1%);
  • "would use again" grew some (36.4% to 38.2%) but
  • "would not use again" grew even more (9.8% to 12.3%).

To be fair, Tailwind is probably more used than ever, but don't take that survey for a statistically strong example.

Collapse
 
xwero profile image
david duymelinck

I think you don't need to overstate popularity. It is not because it is popular it is the best solution for your application/website. The only reason popularity wins is because it has solutions you can copy paste.
People build things because it serves their needs. But you have to figure out what your needs are before saying without this and that every project will fail.

I do more server side code, but i know how important it is to push only the code that is needed to the browser. Doesn't matter if it is javascript, css or html.
On the server we have less of a problem with big codebases because the user only finds out when the response is slow.
For frontend code the penalty is upfront, because the user has to wait until the code that makes the page work is loaded.

Tailwind for me is a good idea, utility classes, that is taken to the extreme. And that is always a bad way to go. Figure out what is the balanced solution for your usecase and everyone is going to be happier in the long run.

Collapse
 
kedzior_io profile image
Artur Kedzior • Edited

I discovered Tailwind too late. I spent many years being a backend developer with a passion for a frontend. I took a great care to style my sites, optimize CSS and make them amazingly looking and responsive.

That was when I had plenty of time.

Now I manage teams and build SaaS platforms and the development time needs to be way more optimized. Tailwind is so good looking and so simple to use that it would be silly not to use it. It makes my teams and myself very productive. We haven't written any single CSS line in ages. On top of that I pay Tailwind UI which let's us quickly glue together the stuff we need. I don't understand how one can hate it.

As an example I did the whole UI for this in less than 2h (including responsive layouts):

salarioo.com

Since we are also talking about React I do understand those that hate React though. :-)

Collapse
 
spotnick profile image
spotnick

Do we know if there is a way to just 'activate' tailwind classes without the integrated styling, e.g. Focus Ring and that? I its pretty annoying. I know I possibly could remove everything with @apply but that is a totally repetitive task for every new project. Any help is appreciated :)

Collapse
 
spotnick profile image
spotnick • Edited

Nevermind, found it with preflight:

tailwindcss.com/docs/preflight

module.exports = {
  corePlugins: {
    preflight: false,
  }
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
joshuaamaju profile image
Joshua Amaju

There's this false idea spreading around that tailwindcss invented utility classes

Collapse
 
collimarco profile image
Marco Colli • Edited

Your example is biased... In CSS you just need padding... not 3 separate lines, like in your example.

Collapse
 
nicolkill profile image
Nicol Acosta

i love tailwind, not defined style, and easy to use css properties, all good

Collapse
 
jhedtmann profile image
Jörg Hedtmann

"The audience was skeptical. Most people thought React was a significant step backward." - at JS ConfUS 29/05/2013

Thats why it was called "React" as in "reactionary"...