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.
