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

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>

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>

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;
  }
}

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

✨ Online demo
✨ GitHub repo

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.

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

• 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

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.

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.

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.

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.

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.

The false dichotomy of the day is this:

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

vs.

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

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.

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!

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.

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>
  )
};

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.