← Previous · All Episodes · Next →
I hate Tailwind CSS. Here's why I use it. Episode 11

I hate Tailwind CSS. Here's why I use it.

· 04:42

|

Mike Bifulco: This is Tiny Improvements.

I'm Mike by ko

I hate Tailwind CSS.

Here's why I use it.

In the first days of building craft
work, I made the decision to use

tailwind CSS for our projects.

This choice was driven by
tailwind's, adaptability, and

its popularity among developers.

Here's the thing, though, tailwind
and I don't really get along.

I've spent years learning to create
design systems with traditional CSS.

More recently, I found myself
building products using full blown

UI libraries like Material UI because
they make it super fast to build a

rich, functional, and accessible ui.

By contrast, tailwind is somewhere
in the middle of these two things.

On some level, it bypasses the
nuance to understanding and control

that came with writing raw CSS.

It's also not fully functional outta the
box like material UI or chakra are, and

yet for so many reasons, it's really good

for us Tailwind provides
some huge benefits.

For example, speed tailwind's.

Utility first approach allows
us to quickly implement designs

without having to write custom CSS.

This is especially useful when
we're iterating on designs and

need to make changes quickly.

Universality at Craftwork are
Stack includes Ruby on Rails next

JS and React native tailwinds.

Flexibility allows us to use the
same styling system across all these

platforms, which is a huge win.

Talent Craft work isn't just me
and it never will be tailwinds.

Popularity across the industry
has made it almost trivial to find

developers who are familiar with it.

This is a huge win for
us as we grow our team.

UI Libraries due to its popularity.

There are many UI libraries that are
built around Tailwind, including Tailwind

UI Shad, CN UI, and ACE Eternity.

UI.

Costs to license.

Each of these libraries vary.

Some are even free, and they're
essentially copy pastable components

that you can use to build your products.

That's very cool.

What this means for us
in practice, tailwind's.

Adaptability is what
really shines from day one.

It has enabled us to onboard new teammates
and build interfaces more rapidly.

It's consistent utility across our
entire stack means that regardless

of the project, new team members
can quickly read, understand,

and contribute to the code base.

The decision to use tailwind
therefore wasn't just about adhering

to current trends or sidestepping
the complexities of raw CSS.

It was a strategic move to ensure
our team can hit the ground running,

maintaining agility and coherence
across our diverse projects.

This underscores a more important
principle in tech selection.

Aligning tool choices with team dynamics
and project requirements is a skill.

It's a delicate balancing act,
weighing the benefits of technological

efficiency and team scalability

against the richness of personal
expertise and the depth of

traditional craftsmanship.

It's a reminder that our growth as
developers is not just about keeping

up with the latest tools or getting
entrenched in what we already know.

It's also about valuing and
honing our foundational skills.

Put another way for everything we build.

We have to balance velocity and quality.

Tailwind is a tool that gives
us wins in both columns.

All that being said, I do still
have a wishlist for tailwind.

I'd love to see better tooling
tailwind's approach to utility first,

CSS is great for performance, but it
also means that we have to configure

tailwind to compile per project so that
it only includes the styles we use.

When this infrequently breaks, it can
be difficult to detect and debugging.

It isn't always straightforward.

I'd also like to see better IDE support.

Tailwind provides a consistent
language for styling our apps.

There are plugins for VS codes
and tele sense that make it

easier to write tailwind classes,
but it doesn't always work.

This can make it difficult to remember
the exact class names for certain styles

and can slow down our development process.

Prettier, prettier rules.

Adding tailwind classes to HTML
means that we often have long lists

of class names added to our HTML.

This causes individual lines of code
to be very long, despite what many

engineers will tell you, this is
demonstrably worse for UX than having

class names listed on separate lines.

There's lots of discussion about
building a prettier rule for

this, but as far as I've seen,
there's not a great solution yet.

So in the end, do I really hate Tailwind?

Well, no, of course not.

I've come to appreciate it for what it
is, a pragmatic choice that has helped

us build better products faster, and
that's something I can get behind.

I had love to hear from you.

What are your thoughts on Tailwind?

Do you have any tips for
using it more effectively?

Is there a UI library
you love that I missed?

Maybe you have a wishlist of your own.

Let me on threads at irreverent mic.

View episode details


Creators and Guests

Mike Bifulco
Host
Mike Bifulco
Developer Advocate, writer, and serial entrepreneur. Into bikes, espresso, and saving the earth.

Subscribe

Listen to 💌 Tiny Improvements using one of many popular podcasting apps or directories.

Apple Podcasts Spotify Overcast Pocket Casts Amazon Music YouTube
← Previous · All Episodes · Next →