Tailwind Isn't for Me (opens in new tab)

Hmm, I’ve always considered tailwind like the spice to make css actually usable, kinda like elixir is to erlang, typescript is to javascript or C is to machine code. Its still CSS just the stuff that you _actually_ want to build is pre-packaged and thought out for the use case.

And I’m not dissing on CSS - just those tools try to solve different problems.

CSS is the ground truth, and it kinda has to support all the weird edge cases and uses that tailwind doesn’t.

Tailwind is like usability overhaul of css, but still allows you to “drop down to css” everywhere you want to.

It can compose like css, but it also constraints you to what you can do. It also gives you tools to group, adjust, refine styles, but in a usable way.

It’s a transpiled language on top of css, but more ambiguous than sass or less.

Given enough time most projects I work with slowly gravitate towards small composable utility classes anyway, tailwind is just logical evolution of that.

And since design peojects usually gravitate towards design systems in the long run, tailwind is really good at facilitating that.

Just because something is old doesn’t mean it’s correct, this is such a curmudgeon take. Things we have have evolved over a long time, have been started hastily (JavaScript) and there’s no reason to believe we’re not in a local minimum and something much better is out there.

I personally believe the js model is completely wrong for the browser and something like an actor model would fit much better.

I’m not saying we should jump on every hype train, and personally really dislike the react ecosystem but I also think we should encourage exploring new approaches. CSS, html and js evolution is driven by the exploration of these new frameworks and they’re very different than what they were just a few years ago

It really depends, for most simple landing pages painkillers are just fine, I've also created extensive dashboards that were used 4-6 years without much iterations, then it's a waste to think too much about css structure. And clients are happy if it looks a bit sexy.

For a long-term project that will require lots of development a more thorough approach would be justified.

And it's not even about what the developers want to do, often it's about what the clients want to hear. I believe in "boring tech" and I'm a late adopter as well, but many clients think of old, dated, outdated, deprecated, unperformant when they hear about a take like this. Often we need to do React just because that's what many clients think the modern UI does. And, in a way, there is a grain of truth to it: since it's also cool with many developers, it's easier to find developers on the market for it, should the project need new people.

With that said, your premise is correct. Prevention is uncool, and safety seems overbearing, preparation is met with "YAGNI". Until people need it.

The multi billion dollar vitamin industry disagrees. Kidding. Only half. I dislike this saying because it doesn't mean anything and just makes some VCs think they're saying something that sounds smart.

There are frameworks that genuinenly improve the development experience for certain uses cases. As with many things, it's important to still now the basics (in this case, CSS), but why not use Tailwind if the philosophy aligns with yours and makes you more productive?

Sure, switching frameworks ever few months to try the hottest shit out there is also not great, and many people overuse frameworks (e.g., React is an overkill for many (most?) applications I have seen). But that doesn't mean there isn't merit in frameworks.

The vitamins vs painkillers analogy is about productivity-boosters vs problem-solvers. Using plain html/css/js is neither of those. You could say Tailwind fits both of them.

I was going reply at the top-level because my opinion is vastly different to the majority of comments so far, until I found yours. Years ago I very much enjoyed finding painkillers to make my work easier. I now only take vitamins.

I'm very much in agreement with the author (regarding Tailwind, I'm Web Component-curious but yet to be convinced to the degree is obviously is...). I started with Adam Morse's "Tachyons" library which is the pre-cursor to Tailwind. Conceptually that worked for me, particularly because I was all-in on the JS ecosystem, building a startup with React and Meteor (story for another time). I wrote up my thoughts on a now-extinct blog [1].

Over time though I found JS to be a fragile and brittle ecosystem to work in; I'm sure as many others have. I not only moved away from SPAs and JS as my backend language of choice to avoid npm dependency hell, but also any JS build tools because using the latter is functionally equivalent to the former.

When my choice of language/framework at the time (Elixir & Phoenix) added support for Tailwind by default, without a JS build tool (handled by an Elixir lib) I was conflicted. I had gotten used to vanilla CSS again with all the new additions such as custom properties and wasn't convinced I needed Tailwind. Even though it didn't bring the JS build chain I hated, it still represented a hard dependency to replace down the line if required, and still required a build tool. It was potentially a decision future me would regret. These days I'm all about not snookering future-me.

I think Tailwind has it's place where you're already using a build tool that can support it (JS or otherwise) and you're working in a team that needs a design system straight out of the box. It gets you up and running quickly (particularly with their TailwindUI components and themes) and provides a point of reference for everyone working on the project without coming up with a design/token system of your own. But that can be said of the older frameworks like Bootstrap or Zurb Foundation (remember that?!).

Personally I'm very happy writing HTML, CSS & JS without any build tools, bar a bit of templating to bring in partials here and there. Admittedly I'm working on very different websites now, but I spend years thinking that the foundations of the web needed augmenting and abstracting away (they probably did at that point...), but now I'm quite happy to work with it in it's natural state.

[1]: https://github.com/jamiedumont/personal_zola/blob/main/conte...

In your analogy, wouldn't tailwind be more of a multivitamin, in that it contains a bunch CSS classes (vitamins) conveniently packaged and ready to go?

I haven't used tw yet, but I intend to because I was blown away by how much sense the authors' book Refactoring UI made.

As a developer from ancient times.. yes!

Why not Styled Components? I've been using them for years now and I'm extremely productive.

Tailwind on the other hand looks like a hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components.

My biggest issue with Tailwind is point #5 on the article: Tailwind encourages div/span-tag soup. Together with the class name soup my HTML becomes unreadable.

> most modern CSS solutions are massively overthought

Example is Tailwind. Which in the end is same as inline CSS.

> read CSS properties horizontally as well as vertically,

What do you mean by this?

Curious: which modern CSS solutions are you referring to?

I love tailwind too. The article did not convince me as there was also no real solution / alternative proposed.

I have written custom css since the year 2000 and using tailwind just makes me much faster (is like setting flags) and simply by reading it, I understand how an element looks like. No matter if my past-self wrote it or another engineer.

It can pollute the HTML (although @apply helps a lot to define your reusable .title, .card, .btn, .btn-lg, .btn-primary etc), but at least it is written in HTML and not in JS, which is even harder to transfer to other eco-systems.

Also extending styles (tailwind config) is amazing if you want to reuse your styles in other projects.

> Web standards will always be slower, which is why we build tooling on top.

I don't follow. I don't see how frameworks or tools have anything to do with standards being slow.

> Do you care about how your html output looks? - I personally don't, just like I don't care about what my Webpack bundle looks like.

It's not a good comparison. You won't ever read the output of your Weboack bundle, but you will surely read the html you write (or worse, is tasked to modify or debug).

also:

- Do you care for bloat user needs to download?

Tailwind is opinionated, meaning it encourages a structure that helps devs avoid common potholes.

You may not like its choices but saying it creates a mess has been the opposite of my experience.

One of the main pitfalls I have noticed no longer running into is that the structure tailwind encourages prevents issues with CSS selector specificity. As a result I’ve definitely noticed fewer instances of ‘!important’ in code review.

I really dislike tailwind too, but I think there is lot of value for lots of people in the idea of having all the styles contained with the template and thus making copy-pasting of code easier without having to deal with the pesky 'Cascade' part of CSS.

Personnaly, I love the cascading part when used correctly, along with the 'latest' evolution of CSS such as 'calc()', variables, on top of using CSS selectors.

> The only reason I think Tailwind is becoming popular now

I think it just matches the way some people think. Nothing more than that.

It's one of many approaches that works well for some people and not for others.

Locality of Behaviour:

"The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code"

https://htmx.org/essays/locality-of-behaviour/

Some people want "cleaner" and that's fine, I much prefer things to be "right there" as much as possible. Must be how my brain works

If you need to adopt the HTML to fit a certain style, you're doing it wrong. HTML should be a semantic markup, it shouldn't change much when you need to change the styling/CSS. So you don't really go "back-and-forth" to architecture CSS, you just write your CSS. But maybe it's a Tailwind thing that you need to add additional elements to HTML just to be able to style it correctly, I'm not sure. It's like saying you shouldn't have JSON files (and embed the data inside the business logic) as you need to change the JSON file when you need to change the logic of the app. In short, you adopt your CSS architecture to your semantic markup, not the other way around.

“Need to switch back and forth” is a strangely negative way of putting it. Do you “switch back and forth” to a function definition, and is that an argument for procedural code and repetition?

Then your second paragraph is a great point against the need for Tailwind and the long class attributes, as you’re going to encapsulate all of that in a component (and “switch back and forth” to see its styles) anyway.

I don't quite get the hate for having CSS in another file. Do you also put all your react stuff in one single file ? That same logic and argument can be applied against all modularization.

And really 20-50 tailwind classes in a single element is VERY hard to read and keep in mind. No - it does not make things clear or understandable. One tends to need to re-read and scan over from the beginning and eyes glaze over. Esp if some elements only vary with a few classes missing. I guess it works for people with very high attention to detail and high amount of working memory. I only find it personally frustrating. With a CSS class applied to that component, one at-least has a singular NAME to refer to that piece of composite styling and your memory can be used for other matters.

Maybe tailwind css works well for some bright, big-memory developers. I did try it for a couple of projects, including needing to maintain someone else's tailwind project - and only felt stupendous pain.

However, the "atomic css" philosophy behind tailwind is great. I find frameworks like https://open-props.style/ a far better application of that principle.

yeah, it works, but try getting back to this codebase in 3 months and then refactor something small. worse, it’s someone else who will have to do it after you.

Did you see that the person who wrote the article also created https://www.vanillabreeze.dev/ to remove dependencies from Tailwind?

Imo, it's correct, assuming there isn't an automated conversion tool. Moreover, Tailwind has a bunch of confusing class names, and certain limitations (as in classes not being available).

What would you suggest as an alternative to enable rich web applications?

Depends on what you're going to use them for. If you need the actual JS functionality web components can offer, then yes. Though at this point you're in JS land anyways and probably using some kind of web component library (or your custom-built helpers/wrappers/etc.), which usually handles this for you.

If all you want to do is prevent the "div/span-tag soup" as he calls it, you don't have to register anything, though. You can just write <ui-card><ui-card-header>My header</ui-card-header></ui-card> and style that using regular CSS à la ui-card { background-color: red; }.

You can use custom tags just like any other native tags without any js, they just work

I will be sharing that hill with you, if you don't mind.

And the HN title should include (2021)

I'd like to like web components, but their reliance on JS to instantiate along with all the chaos of the shadow DOM keep them off the table for me. I think they are a great concept defeated by the implementation.

https://www.vanillabreeze.dev/ (by the author of this post)

Tailwind to CSS: https://tailwind-to-css.vercel.app/ CSS to Tailwind: https://transform.tools/css-to-tailwind

What is tendinitis/RSI/carpal tunnel?

what about maintain a product? ship improvements and changes to the product?

I don't feel that a simple upvote is enough to express my support for this statement. I'll +1 this all the way to retirement!

Technology-choice as fashion needs to die. There are suitable tools for the job, and unsuitable ones. Deciding between them gets harder when loads of amped up juniors are selling each other on the benefits of the latest and greatest without actually putting them to the test over the course of years/multiple projects/iterations.

Exactly. I had the luck of working with a codebase that knew how to harvest the power of vanilla CSS (though vanilla CSS in 2020 was already the same as vanilla CSS in 2014), and it's quite powerful. Add to that the browser devtools and it can be very productive.

HTML itself is beautiful. Show me a better way to express varied words and images with an eye for creative layout and design the way great books play with this content.

Every design system build on top of HTML is just an abstraction that adds layers of complexity whilst reducing the inherent flexibility of HTML. It's much like the years when every SPA framework rebuilt the concept of a back-button and page history, or standard HTML form inputs. All were shittier versions of what the browser provided (even if imperfectly at times).