
Tailwind: style your site without writing any CSS - dankohn1
https://jvns.ca/blog/2018/11/01/tailwind--write-css-without-the-css/
======
shubhamjain
How would have React adoption looked like if it wasn't backed by a tech giant?
React propounds a very controversial idea: to put HTML inside Javascript. Of
course, once you get the hang of it, it all makes perfect sense: tight
coupling and composability.

Tailwind, along the same lines, proposes a contrarian idea and it will only
make sense once you start working with it. Here's what I have seen happen
frequently: As the CSS grows, so does the bloat and repetitiveness of the same
basic style. Let's say you want to position elements in the center of a
component? "display: flex, align-items: center" easy. But what do you do when
you encounter that same requirement again? Creating a utility class and
replacing existing once will be a pain, so you add the same styles again. And
that's how folks you end up with a megabyte of CSS doing a job that could be
done in <100Kb.

This pattern is more pervasive than you think. The fundamental problem is that
we are not thinking about styling in terms of composability of basic styles.

The benefits of utility classes outweigh the cons. You can iterate faster, you
don't have to fight the framework, you don't have rethink abstractions at
every point ("this style belongs to a component or a utility class") and as
CSS becomes more expressive you'll need fewer classes anyways. I hope Tailwind
takes off because styling definitely needs to be less painful than it's today.

~~~
jacamat
The benefits absolutely do not outweigh the cons. For starters, your CSS can
never compile down to a smaller size than component CSS - ever. Because of the
nature of compositional classes the plateau of problems expands out almost
infinitely, and the resultant inconsistencies necessitate new overrides, more
code, more complexity, more misdirection.

What size site do you work on? How often do you have to completely change an
interface, or move a component from one place to another without it breaking
_at all_ , and how well does that work for you with Tailwind? How do you plan
to scale this codebase consistently across organizations, teams, potentially
platforms?

Tailwind and the frameworks like it are absolutely terrible at scale. I've
spent years of my life trying to remove functional css from sites trying to
scale while it holds them back.

~~~
jonathanreinink
Co-author of Tailwind CSS here. Prior to building Tailwind, I followed more
traditional approaches to writing CSS, like BEM. In fact, I remember when BEM
first came out, and people hated it too. I've worked on small projects, and
very large projects. I recently rebuilt a large web app using Tailwind, and my
resulting CSS was TINY. I use Tailwind in conjunction with Purge CSS. The
resulting filesize was 8.1kb gzipped (42kb).

> Tailwind and the frameworks like it are absolutely terrible at scale.

My experience has been the opposite. BEM is terrible at scale. You write the
CSS, but then never dare change it, because you have no idea of the
consequences of those changes. Developers end up duplicating BEM components
for their use case, because it's safe. Which just leads to more CSS code. It's
also worth noting that we're seeing more and more large companies move to
utility based CSS, including GitHub and Heroku.

~~~
TimTheTinker
At scale, the priority is isolation of components. This allows things to be
composed, moved, etc. without affecting each other.

We accomplish this in our web app (over 500 kloc) by simply giving each
component’s top-level element a unique, formulaic, memorable CSS class (which
is very easy to do with SASS/SCSS). And each component gets its own CSS (or
.scss) file, HTML file, JS file(s), and I18n directory. The app loads each
component’s CSS when that component is loaded at run time (which could be
during startup or later). I just don’t see how one could get more
straightforward than this for a large app.

We do have some classes that are included in the base-level stylesheets and
shared among components, but we only use those when it would result in less
code than not, or when necessary for themeing.

It may take a lot of effort to build this kind of architecture, but once
you’re there it’s a breeze to create, compose, and maintain UI components.

~~~
cbhl
The problem with isolation of components is that then the stylesheets are no
longer cascading -- each component needs to be re-designed to fit within a
design framework, and there's no CSS reuse between components is entirely
copy-and-paste. Good luck re-styling anything for "dark mode" without having
to hand-visit each component's JavaScript and CSS.

Plus, component isolation has really slow polyfills. None of the Google stuff
as of late runs on anything other than Chrome for like a year after launch
because it's too slow and broken -- everything is being rewritten in Polymer,
which relies on browser support for component isolation.

~~~
jacamat
Avoiding the cascade is kind of the point, although I'm sure that sounds
antithetical. IMO, the cascade should be treated with an "opt-in" approach,
where you have a fine degree of control over what, precisely, is cascading and
why.

In general, with component CSS, you will tend to avoid the cascade, except
within your component. This is actually where utility classes have some value
- if they're scoped very tightly to the parent, and their effects are well-
understood - then your single purpose class can add an easy way to do simple
updates.

That being said, for my part, and on my own website (doggos.com) we do not use
any form of utility classes whatsoever. The entire website depends upon
isolation, and through this isolation, I have a degree of control that I've
not found in applications that have opted for other methods.

In short, it's worked very well for us.

As for your dark mode example... you should take a look at how Apple made dark
mode a reality with their new Mojave update. I think you will be surprised at
the level of isolation their interface demands and, although we're no longer
talking about the web here, just how easy it was for them to
implement...relatively speaking.

In short, I can make a site go dark with components, no problem.

------
armandososa
This is not for me. I am very good at, and very comfortable writing CSS since
I've been doing it since the CSS Zen Garden days. But I understand the pains
this is trying to solve and I think that this is the wrong approach and also
the wrong abstraction.

\- If you don't like CSS, this will not help you write less CSS, it will only
make you write it inline and using a weird syntax.

\- If you want to do the sensible thing and compose your styles into
components then you'll still have to write CSS with the weird syntax and add a
PostCSS to your dev pipeline. Not to mention that you'll still have to have
some kind of system for your class naming.

\- The order of the clases does not matter, the specificity is decided by the
order in which they appear in the source. I can see all kind of untraceable
bugs coming from that.

I've used BEM and SMACSS and similar before and I think they are useful as a
naming convention for teams but I don't think of them as great tools to
writing better CSS. In my humble opinion CSS-in-JS solutions are closer to a
great abstraction. I quite like both StyledJSX (for react) and .vue files in
which you can write plain css and forget about the global aspects of CSS and
the cascade for the most part.

But I can see why some people will dislike that as fiercely as they dislike
tailwind.

I think Styled System is a better abstraction than tailwind:
[https://github.com/jxnblk/styled-system](https://github.com/jxnblk/styled-
system) it's a React library but I can see it's principles could be extracted
successfully to plain CSS.

~~~
chrisweekly
Tailwind and CSS-in-JS are not mutually exclusive! On the contrary, they're a
terrific match!

~~~
nojvek
Not really CSS in js is basically applying styles directly to an element, this
one declares a small style sheet upfront and classes on elements are looked up
to get style information.

Css in js is very efficient if you don’t need any css inheritance. Tailwind is
just inefficient for the browser to do all those lookups to resolve the final
style bag.

I’m not sure why I would ever use tailwind. It’s yet another archaic syntax I
have to keep in my head.

~~~
chrisweekly
Sorry, but, respectfully, you misunderstand tailwind in the context of css-in-
js. This post might make a better case than I have time to right now:
[https://github.com/jlengstorf/gatsby-tailwind-
demo](https://github.com/jlengstorf/gatsby-tailwind-demo)

------
dna113
Lol here we go again. Why does this get people so riled up?

I suspect people who immediately dislike this maybe are not using some type of
component-based UI. CSS classes are all about code-reuse. If you have the
concept of say a "button" in your UI, and you are copying your button markup
every where you use that "button" then it certainly makes sense to have a
class for your button markup that encapsulates the styles for that button in a
style sheet somewhere.

If using a button component however, you've already created a place for the
concept of your button to exist. At that point if you go on making a class in
some style sheet that also represents the concept of your button, now your
button concept exists in multiple places, linked together by one or several
class names. That seems a lot messier to me than using utility first styles,
but I don't think it really makes a huge difference one way or another.

~~~
wishinghand
This can easily be accomplished with SASS and a methodology like BEM. And it
makes the markup a lot easier to read.

~~~
stefanfisk
after doing a project with tailwind I have completely abandoned the idea of
BEM. while it was nice having clean classes, having the styles directly in the
html is way easier to reason about.

~~~
colonelpopcorn
We're back to filling in style attributes on each tag, aren't we?

~~~
nihonde
Not quite, because you can still define thematic defaults and change those
globally to suit any changes to your style book.

------
SunboX
I really don't see the benefit. Sure, you don't write "CSS", but you write a
lot of classes that look like CSS. If you write class="bg-white no-underline"
you could easily write style="background: white; text-decoration: none;" and
every frontend guy will understand it. I don't get the point.

~~~
mattferderer
If this article didn't make it click for you, that's understandable. It took
me a long time of hearing about this & thinking it was stupid before it made
sense. When that happens to me, it's usually a sign of something good.

The author of Tailwind suggested I read his best effort at explaining why this
makes sense.: [https://adamwathan.me/css-utility-classes-and-separation-
of-...](https://adamwathan.me/css-utility-classes-and-separation-of-concerns/)

Towards the end of the article it started clicking for me.

~~~
paulsutter
Easier just to quote the reason he gives:

“With inline styles, there are no constraints on what values you choose...
Utilities force you to choose...

You can't just pick any value want; you have to choose from a curated list.
Instead of 380 text colors, you end up with 10 or 12.”

~~~
jacamat
in what way is that consistent tho?

~~~
neurotrace
In what way is it not? You'll consistently get 10 or 12 colors instead of
getting an inconsistent set of colors, for example.

~~~
jacamat
But I only want the element to be the color it IS, not a range of colors it
could be. Whats to stop a dev using $concrete when they should be using
$cloud? or $linkGray instead of $headerLinkGray?

these inconsistencies compound, especially across teams.

~~~
neurotrace
Nothing would stop them from choosing to use cloud vs. link gray but it's far
easier to identify and fix those cases than it is to have #CCC, lighten(#CCC,
10%), etc. around the codebase. This doesn't fix human error, just reduces it.

------
Raphmedia
Sounds to me like the author should simply use SASS + a good autocomplete
feature in their IDE.

When I write CSS, I use a lot of shortcuts. I simply write "mt5" and then
press tab, it then auto completes to "margin-top: 5px;". If I write "tdu"+tab
and then it goes "text-decoration: underline;". The IDE also shows me in a
drop down all the options that can be used after writing "text-decoration".

Changing standards because you do not want to learn or remember something is
the perfect example of programmer "laziness". Why remember this super common
language when instead I can develop and remember a new obscure abstraction
instead?

~~~
mbrock
Oh no, laziness! Someone is doing something in an easy and convenient way that
somehow doesn't match up with other people's ideals of conceptual purity! :'(

~~~
Raphmedia
Bloating your markup with classes is simply a bad habit. It bites you hard in
the long run.

Even the framework that they are using proposes better alternatives.

“ _Tailwind encourages a "utility-first" workflow, where new designs are
initially implemented using only utility classes to avoid premature
abstraction._

 _While we strongly believe you can get a lot further with just utilities than
you might initially expect, we don 't believe that a dogmatic utility-only
approach is the best way to write CSS._”

Read this page: [https://tailwindcss.com/docs/extracting-
components/](https://tailwindcss.com/docs/extracting-components/)

A class based rapid prototyping framework is a powerful tool, don't get me
wrong. However, like all tools you should only use them when they truly are
needed.

~~~
corobo
Could you suggest how it's bloating the markup and how it'll bite you in the
long run?

I understand that maybe adding a bunch of classes for every element will
increase the overall size of the page but if it's served with gzip compression
doesn't it actually (maybe only technically) work better to have repetitive
classes everywhere instead of unique class names?

~~~
Raphmedia
Adding some classes is alright. Things like "row", "column-6" are tolerated
evils.

Look at the button from his article:

<a class="text-xl rounded bg-orange pt-1 pb-1 pr-4 pl-4 text-white hover:text-
white no-underline leading-loose" href="#">Buy for $10</a>

That's way too granular.

~~~
corobo
So you're just talking in terms of visual bloat?

On this page it documents how you can create component classes
[https://tailwindcss.com/docs/extracting-
components/](https://tailwindcss.com/docs/extracting-components/)

    
    
       <button class="btn-blue">
         Button
       </button>
    

Then in your style

    
    
       .btn-blue {
         @apply bg-blue text-white font-bold py-2 px-4 rounded;
       }
       .btn-blue:hover {
         @apply bg-blue-dark;
       }

~~~
Raphmedia
The problem with granular classes is that you project won't scale in an
efficient way. It also makes refactoring almost impossible.

On a small one page website, do use them. However in something more complex
like an e-commerce website theme or a complex web app, you will regret it
quickly.

<a class="text-xl rounded bg-orange pt-1 pb-1 pr-4 pl-4 text-white hover:text-
white no-underline leading-loose" href="#">

is no better than

<a style="font-size:16px; border-radius:5px; background:orange; color: white;
text-decoration: none;" href="#">

It is simply a fancy way to use inline styles.

One of the selling points of CSS is the ability to scale and refactor very
quickly and easily. Class based frameworks remove all those benefits.
Extracting components and building sementically is the solution. As I said in
my previous comment, that framework they are using supports it. They say it
themselves:

    
    
        “*While we strongly believe you can get a lot further with just utilities than you might initially expect, we don't believe that a dogmatic utility-only approach is the best way to write CSS.*”
    

I have worked on many contracts where the client came to us because their
current web agency wanted to charge crazy prices to refresh their website's
design (e-commerce websites change at least one a year). Almost every time,
those projects are a pain for both the team and the client because the
previous developer decided to be lazy and use classes or inline styles
everywhere.

------
peeters
It's 2018, does CSS supported by modern browsers still lack the basic building
blocks of reuse? Why am I being asked to choose between class="resources" (and
having to know how to center a div in that resources class) and
class="t:center t:wide-margins t:light-bg" (which is basically reintroducing
all the harm of style tags). Why can't I, in 2018 and with vanilla CSS, say:

    
    
        .resources {
          @include .centered
          @include .wide-margins
          @include .light-bg
        }
    

It seems like every one of these styling tools is just polishing a turd that
is a turd for no reason. I can't imagine why the above would be difficult, it
wouldn't have to change anything about the actual application of CSS rules, it
could literally just be a simple preprocessor.

Sure give me a library of common ways of doing something. That's great. But
the lack of basic code reuse for CSS is staggering. Even if you're doing reuse
with SASS you're stuck with the fact that you end up generating a CSS File
that's 4-5 times larger than it needs to be.

~~~
err4nt
What's wrong with class="centered wide-margins light-bg"? It would do the same
as what your .resources class looks like it might do, and it's supported
everywhere already.

~~~
peeters
Nothing when everything's a one-off and you only have one supported theme. But
if CSS is your component model (e.g. a card is always just a div but with a
special style) then you'll have "centered wide-margins light-bg dropshadow" on
every one of those divs, rather than just class="card". Similarly if you want
to have two different themes with the same DOM, you can't do so easily.

~~~
jaydid
Nobody who uses Tailwind would suggest copying the same classes over and over
again in the example you’re talking about. You would either still create a
card component (Tailwind does have the concept of components), or if you were
using a framework like Laravel you could create a card blade component that
held the tailwind card classes in one place.

~~~
peeters
I wasn't talking about Tailwind, I was talking about vanilla HTML and CSS. I
assumed the question asked of me ("what's wrong with"...) was asked in that
context.

------
ludlu
I've been using tailwind for almost a year and I love it. I would not use
something else willingly for something new! Its easy/fast to write and in my
mind VERY readable, and if you don't know whats what, their docs are really
good.

And for example in React to build a component with conditional styling I use
classNames and use props that correspond to classes.

[https://github.com/JedWatson/classnames](https://github.com/JedWatson/classnames)

------
Isofarro
It puzzles me why these Atomic CSS based systems use various mnemonic systems
instead of plain English which is much more understandable. I'm not a fan of
human-powered text compression.

~~~
judofyr
It's based on how often you use a helper. For instance, changing letter
spacing is verbose ([https://tailwindcss.com/docs/letter-
spacing](https://tailwindcss.com/docs/letter-spacing)) as it's not something
you use that often. Tweaking spacing is _very_ common and "padding-
horizontal-2" uses an awful amount of characters.

~~~
Isofarro
In what context is this "an awful amount of characters" an issue? GZip
compression is fairly standard these days, and languages based on plain
english (or similar languages) has a better level of compression than random
text because of repetitive nature of sequences of characters.

I can't believe that mnemonic based languages are easier and more readable
than something closer to a natural language. And with the assumption that code
is written for humans first, computers second, what is the point of inventing
a language that's less readable than the one it's trying to replace? CSS
compresses particularly well, as every Atomic CSS based framework tends to
point out on it's landing page!

~~~
judofyr
It's an awful amount of characters once you multiply it. For instance, the
first example ([https://tailwindcss.com/docs/what-is-
tailwind/](https://tailwindcss.com/docs/what-is-tailwind/)) would be twice as
big:

    
    
        <img class="block h-16 sm:h-24 rounded-full mx-auto mb-4 sm:mb-0 sm:mr-4 sm:ml-0"
    
        <img class="block height-16 small:height-24 rounded-full margin-horizontal-auto margin-bottom-4 small:margin-bottom-0 small:margin-right-4 small:margin-left-0"
    

After spending more than, say, two hours with Tailwind you'll probably read
the first line much faster than second one (since there's less to read and you
don't need to scroll). Humans are very good at pattern recognition, and you'll
quickly read "mb" as a symbol in itself and not as "m[argin] b[ottom]".

> I can't believe that mnemonic based languages are easier and more readable
> than something closer to a natural language.

Well, it's worked out pretty well in mathematics. This is _not_ about file
size at all. It's about defining an "alphabet" of common concepts.

~~~
Isofarro
Ah, I see your issue: you do know you can have whitespace inside attributes?
You don't have to clump all the class names on one line. Scanning vertically
is quicker than through the horizontal line-noise of both your examples.

    
    
        <img class="
            block
            height-16
            small:height-24
            rounded-full
            margin-horizontal-auto
            margin-bottom-4
            small:margin-bottom-0
            small:margin-right-4
            small:margin-left-0
        ">
    

This also has the benefit too, that if you use version control line-based
diffs to see what's changed, it will highlight the specific css class name
that changed. Handy if you need to ensure that whenever you change the bottom
margin, you can see at a glance whether the small prefixed one has been
updated too.

On the other hand if you regularly need that many classes to style an element,
perhaps it's a good place to refactor commonly occurring class names into a
set, and label that set with a meaningful identifier.

As for mathematical notation, it's about as understandable to me as my
understanding of Hanzi.

------
baxtr
Tailwind is really awesome. I switched from bootstrap in some projects and
it’s been great. You gain a lot of flexibility in your designs

I recommend this post by Adam to anyone who is interested in learning more
about utility first CSS.

[https://adamwathan.me/css-utility-classes-and-separation-
of-...](https://adamwathan.me/css-utility-classes-and-separation-of-concerns/)

------
Heliosmaster
I use Bulma (discussed at the end) for all my projects. It's very easy and
quick to get started with, but I found myself diverging from this style when I
was starting to add new CSS of my own, to get the pages to look exactly how I
wanted them.

And due to the lack of tooling, it's hard to refactor CSS (removing duplicate
code, etc.) so I'm not sure how scalable it is to adhere to what the OP says
for a long time.

~~~
mahesh_rm
I never tried Tailwind, I landed to Bulma after using Bootstrap, and then
Tachyons, for many years, and I really enjoy it. I find myself maintaining an
helper.scss file with basic classes that bulma does not support out of the
box, but other than that, it definitely saves me time and, overall, improves
the outcomes.

~~~
ealhad
Tailwind is basically Tachyons + a bunch of features.

Last time I migrated a project from Tachyons to Tailwind, it was quick and
painless.

------
jacamat
Everytime I see Tailwind/Tachyons/Functional CSS at the top of HN I die a
little inside. I've said it before and I'll say it again: if you actually like
this kind of CSS, you probably don't work on large websites. And when you do,
the reason people hate it so much will become abundantly clear to you.

Functional CSS makes for an unscaleable, inconsistent, unmaintainable dumpster
fire of styles that is _objectively_ worse than just writing regular CSS.

<sarcasm> But it's convenient, right? So who cares! AirBnB, Facebook, Walmart,
Github, and Twitter are all probably wrong anyway. </sarcasm>

~~~
adamwathan
GitHub has been switching to functional CSS over the last couple of years:
[https://primer.style/](https://primer.style/)

I interviewed Diana Mounter who leads their design systems team about this a
while back:
[http://www.fullstackradio.com/75](http://www.fullstackradio.com/75)

~~~
jacamat
I'll definitely respond to this more later. ;)

------
robotmay
I've been using Tailwind lately and I really like it. It lets me prototype and
iterate quickly, and then when I've settled on a design I can create component
classes for those completed styles. It has made doing frontend work slightly
more bearable for me.

------
simonswiss
Lots of comments in here echo the initial gut reaction we all have when first
encountering utility class composition.

"What about semantic classnames? Separation of concerns? It looks ugly, is
going to be hell to maintain, won't scale.. may as well use inline styles!"

I did a conference talk about my own experience moving from BEM to utility-
first CSS, you might find it interesting

[https://vimeo.com/294976504](https://vimeo.com/294976504)

------
Tade0
_Most (all?) of the classes apply exactly 1 line of CSS._

I see this as an anti-pattern, because to me it looks like inline styles with
extra steps. The only thing it avoids is accidental strong specificity.

The reason we have CSS is that it's really easy to make HTML unreadable -
after all it's essentially a 1D medium(lines of text) trying to describe a 2D
space.

~~~
wes-k
Inline styles = open ended, while classesrestrict you.

Also this is switching things around. Now your html depends on your css
classes and not your css depending on your html. No more broken css when a dev
modified the html structure and didn’t realize that one of the hundreds of
lines of css now doesn’t get applied right.

~~~
Tade0
_No more broken css when a dev modified the html structure and didn’t realize
that one of the hundreds of lines of css now doesn’t get applied right._

You can achieve the same, but with much less clutter using BEM. Or even
better: BEM + SASS.

------
Zag24
Doesn't this essentially put you back to the bad old days of style attributes?
Sure, the "styles" you are using are much more clever and they adapt to screen
sizes, etc., but you are still putting the specific style you want an element
to have in the element itself and not getting any redirection.

Say you have an entire application with a dozen primary pages, plus several
dozen modal windows and other sub-pages. If you want to make a global change,
like, "Change all the OK buttons in my entire application to have rounded
corners and a gray to red gradient" then you have to go back and make a change
to every button you have in the application. The whole idea with changing the
CSS was that I defined a semantic CSS (e.g. "OKButton") which I used in all
the places that had a common meaning, and then I could change the look of the
entire application in one place.

------
wolco
I have trouble with the following statement. Complete flexibility is a bad
thing? If I accept that how is limiting options to 30 not providing too much
flexibility?

"Limits & standards. With normal CSS, I can make any element any width I want.
For me, this is not a good thing! With tailwind, there are only 30ish options
for width"

~~~
notjustanymike
Actually it is, especially when you're working with a team of developers.

Imagine that your designer puts together a design system built on a soft grid.
The rules in the design system are what ensure consistency across the site.

If you have a team of developers, sooner or later you'll manage a junior dev
who interprets the design as a pixel perfect layout, and starts defining
widths on elements per their own personal interpretation. Maybe they eyeball
it, maybe they measure it, maybe they measure it but don't include the border.

You can catch such things through training and code review, but it puts the
burden of managing design consistency on a senior engineer. Starting out with
a constrained system is one easy way to ensure consistency of design across
large projects.

------
smpetrey
A neat concept — perhaps two years too late.

I fear that many will not prefer attribute bloat in their markup.

And many are moving to React, does this sort of toolset matter anymore? Not
being negative, genuinely serious. Does this tool make sense for apps going
forward? To me it seems Tailwind is for little html things.

~~~
metafunctor
If anything, utility CSS frameworks and creating reusable CSS (as opposed to
reusable HTML) make more sense when used with something like React.

------
wes-k
I was definitely hesitant when I first heard about this. After working in a
codebase that uses CSS utilities, I gotta say, this is awesome!!

I plan to use tailwind in all future green field projects!

Enforces style, kills duplication, speeds up development. Ahh the benefits are
huge!

------
poof_he_is_gone
I prefer the hybrid approach, having a mix constantly repeated utility styles
for things like padding, margin, floats, and colors, and then having custom
SCSS/CSS for the rest.

~~~
stefanfisk
that's what tailwind does, look into the components docs. essentially
utilities vs components are a matter of definition order, such that utilities
can always override components.

------
androidgirl
I really like these atomic/functional css libraries with any sort of frontend
framework or templating system that leverages components.

Personally, I have been using Tachyons with React for the past couple months,
and it's been a blast. Compared to writing html templates with Emmet and css
with Sass, I feel as if I am more productive and like I can reuse more
components.

It's worth a try if it interests you!

~~~
chrisfrank
I've also found Tachyons & React to be an amazing combination. The only
trouble I've had is extracting common CSS class strings into tweakable
components, e.g. a <Button> whose background color you can easily override, or
a <Header> with tweakable font weight.

I wrote a tiny (1kb) library to make this easier. For anyone working with
React and functional CSS, I hope it's helpful:

[https://www.npmjs.com/package/nanostyled](https://www.npmjs.com/package/nanostyled)

~~~
androidgirl
Seems like an interesting library! I also encountered this issue, but I ended
up just passing in colors/borders/spacing as props. I will have to see how
that holds up for complicated UIs.

~~~
chrisfrank
Thanks! I started by just passing props too, and I could see that approach
working forever. I just got tired of having to always specify <Button
bg="blue" border="ba1" />, when 90% of the buttons in the app were blue with a
border.

------
leejoramo
Be sure to check out the Wizard Zines site they are talk about. It had old
school hand drawn zines about topics such as git, debugging, and more. Here is
one on tcpdump

[https://wizardzines.com/zines/tcpdump/](https://wizardzines.com/zines/tcpdump/)

Reminds me of many computer publications in the early days

~~~
wpietri
Absolutely. She's really good at making a complex topic approachable and
bringing a lot of excitement as she shows you around. It reminds me how
incredibly cool I thought these tools were when I first learned them.

------
mfontani
Style your site with "only" 291KiB of CSS (24KiB compressed)?

~~~
baxtr
Please read this...

 _> By comparison Tailwind seems really heavy (over 1.5x larger than
Bootstrap!), but it turns out that this comparison isn't totally fair._

[https://tailwindcss.com/docs/controlling-file-
size/#app](https://tailwindcss.com/docs/controlling-file-size/#app)

~~~
jermaustin1
But couldn't you also do the same to Bootstrap with PurgeCSS and still come
out ahead of Tailwind?

~~~
adamwathan
Tailwind would come out ahead because there are fewer classes that contain the
same declarations, so the total number of style declarations would be less.

------
dpau
Here's a single-page cheatsheet I created for Tailwind, good for seeing
Tailwind's utility classes at a glance:
[https://derekphilipau.github.io/tailwindcss-cheatsheet-
singl...](https://derekphilipau.github.io/tailwindcss-cheatsheet-single-page/)

------
jmhnilbog
What percentage of software churn is based on developers being reluctant to
call out mistakes by other developers on their own teams/in their own
companies (while having no problems calling out flaws in internet strangers'
code)?

'Curating' what developers are allowed to do has been the focus of the last
few jobs I've declined. "The guys at the other office are too dumb to learn
(React|Angular|CSS|tech X). Obviously, we need a team to invent something that
uses (React|Angular|CSS|tech X) behind the scenes but has a totally different
API and no easily searchable documentation or support outside of our company."

Tailwind looks like one of those escaping into the world, when telling your
devs to pay attention to a style guide would have been the easier solution.

Technology does not have a glorious track record in solving cultural issues.

~~~
RyanShook
Not sure it totally applies to this situation but agree and think this is a
great point. Technology doesn't solve cultural problems and often exacerbates
them!

------
trwhite
Several people here say "this doesn't scale" but I'd be curious to find out:

\- The 'scale' at which they think a framework like this doesn't work (number
of users, devs etc).

\- The scale of the projects they work on.

Who even says a framework needs to be adopted by tech giants or work at
'scale' to have any credibility?

A utility-based approach has been adopted at the last 2 companies I've worked
for and it's been very effective, often when working with very complex designs
on medium-sized sites (that serve less than 100k users/month).

Some of my previous colleagues and I work on
[https://github.com/friendsthatcode/flavourcss](https://github.com/friendsthatcode/flavourcss),
which was inspired but some of the ideas behind Tailwind and our own work.

------
lmm
I've been saying for years that, in these days where all HTML is generated,
CSS makes no sense and we might as well just style inline. You probably
already have a "button" class in your UI framework that contains the HTML for
rendering a button; put the styling there too.

~~~
blinky1456
So if you have a large number of buttons or other elements with the same class
you will be repeating yourself over and over.

With elements with a large number of style rules, you add a lot of very long
lines to your html.

This would be a nightmare to work on/maintain.

~~~
lmm
> So if you have a large number of buttons or other elements with the same
> class you will be repeating yourself over and over.

In the HTML, sure. But so what? It gets compressed in transport so there won't
be significant overhead there (similar to how remote desktop protocols that
send images with compression turn out to be just as efficient as those that
tried to send intelligent drawing commands), and the browser has to compute
the final style for each element anyway so there's no overhead in-memory
either.

> This would be a nightmare to work on/maintain.

HTML is an output format, you don't edit/maintain HTML any more than you
edit/maintain binary machine code. And keeping the styles inline allows better
encapsulation: the styling for each component lives in that component, you
don't have the spooky action at a distance of child selectors.

~~~
icebraining
What frameworks treat HTML as an output format, and what is the input? When I
see samples of React code, all the HTML (in the form of JSX) is still
handwritten, just combined dynamically.

~~~
lmm
Sure - you write the html snippets by hand (and those are still very
maintainable if you use inline styles). But you don't maintain the final page
that might have e.g. twenty buttons, so that's not a case to optimise for.

------
owenmelbz
Too much to read xD if anybody gets this far then remember this...

1\. People arguing against this are arguing against utility classes and not
arguing against tailwind.

2\. Tailwind is different - it’s a toolset allowing you to build your own
framework - you can use the tailwind config to define your variables and use
BEM or what ever you want.

3\. Tailwind is utility “first” - so it provides all the utilities you need,
YOU decide how to use them, put them all in your HTML if you like, or make
components out of them, include them into an existing project, etc.

So everybody here who is being negative towards tailwind regarding utilities
is wrong - because they haven’t understood tailwind. - your arguments may be
valid for utility classes, but this topic is about tailwind, so your spreading
misinformation.

------
H1Supreme
To address the author's “oh, another bootstrap site” line, Bootstrap offers a
"css grid only" option. Which, I've found to be great when you don't want the
Bootstrap look, but want a grid system in place to build with.

------
PunchTornado
I don't understand how this works.

Say you want a div to be a specific width: 135px, how do you make it without
writing any CSS? Or you want a specific shade of a colour? Or you want to
style things that are not in your html (third party widgets).

~~~
deltron3030
You treat your stylesheet as your style guide, design system, or single source
of truth. That's where you define your fonts, colors scales etc.

So you actually don't have to think about specific widths while you're
building, you reference a width that is already set up in your stylesheet!

I find that it improves the design to dev workflow. You experiment with design
in a design tool like Sketch, and then translate your final idea or rules into
a stylesheet, which is the basis for your live prototyping in editor & browser
(wrapping HTML elements and referencing styles in your stylesheet).

------
Lennu
These packages are really useful for small to medium sized projects where you
need little to no customization! When you do need something greater than what
the package can provide then I find it better to use something else because
these tend to pollute the namespace and things in my experience get really
complicated when you start adding your own stuff with them, or modifying them.

Even though they are compact you probably end up having lots of unused CSS
code in your website.

------
ukyrgf
I've seen Tailwind pop up in some of the JAMstack starter kits, and I could
have sworn it was some framework of yesteryear that I just missed that was now
largely replaced by Bootstrap/Bulma/etc. Now that I've looked at the GitHub, I
see v0.1.0 was released on Nov 1 2017! Some of these recent trends in web
design really have me scratching my head, but I guess I'm just getting old.

------
nickthemagicman
If you use Sass you get both the benefits of semantic html AND the ability to
jam a million classes into an html element with @include and @extend.

------
z3t4
CSS has a bit of a learning curve, the probably most difficult to understand
is the C (cascading ) part, and where something more specific over-rides
something less specific. It's simple. Yet complex. But it's very powerful to
be able to change the look of something, without touching the code that makes
up the site/app content. And change theme by replacing the CSS-file.

------
mfbx9da4
[http://basscss.com/](http://basscss.com/) Is another tailwind type

------
projectramo
When I make something, I want _all_ and _just_ the relevant pieces of what I
am doing in my face, and then I want them gone when I do the next task.

So if I were to every try to design a page, I want all the relevant design
items there when I am figuring it out, and then when I am done, I don't want
to see them again.

So if you spend a lot of time designing the html/css then this approach makes
sense. I don't want to jump into the css file and then back in the html file.

However, if I want a particular look and feel for a site, and then knock out
the css, then I want the css in a different file and then I want to focus on
the layout and the logic.

So my guess is that the original author builds lots of new sites and moves on.
My guess is that the original author does not build one large site for a large
company that has a consistent look and feel for years (till the rebrand).

------
fiatjaf
For people who disagree, the CSS zen garden approach lives on on my blog-theme
compilation: [https://classless.alhur.es/](https://classless.alhur.es/)

------
rozhok
There is similar project called Tacit —
[http://yegor256.github.io/tacit/](http://yegor256.github.io/tacit/)

------
Aeolun
I honestly do not see the point in giving each of my css properties a separate
class and then sticking those in my HTML.

If I wanted to do that I would have used the ‘style’ tag.

------
RyanShook
How is tailwind different than bootstrap or the multiple other css frameworks?

~~~
jaydid
Well Bootstrap is a not a functional css framework like Tailwind. A better
comparison would be Tachyons.

------
de_watcher
When your styling tool (CSS) doesn't do what you actually need (layouts).

------
badsavage
this is stupid, hard to maintain and ugly as well

------
combatentropy
> Web design really isn’t my strong suit [...] for probably like 12 years now
> [...] and am making no efforts to improve

Is this ignorance common among those for whom functional CSS makes sense, or
are there any CSS experts who like it? I'm bewildered by the popularity, as I
am by several other fashions.

Sometimes I wonder if these choices come from blog-driven development. I used
to feel a bit insecure that I didn't go to school for computer science. I
tried to make up for that by reading books, many books, cover to cover.
Reading a great book cover to cover gives you a coherent understanding of the
beginning, middle, and end of a language or tool. Also I read references: the
list of core PHP functions, the jQuery API, and the list of CSS attributes. I
didn't memorize them. I just tried to understand the gist of each, filed in
the back of my mind, enough to prod me to find it in the reference when I
needed it. But if you are learning by blog and Stack Overflow, do you ever
come to an overall, comfortable understanding of something?

I grant you that it will take some time, but so does learning these
frameworks. The frameworks seem to fix one problem while planting three more.
And Julia Evans is a technically minded person. She has written about Git and
the Linux command line. Which is more complicated, Linux or CSS? I had always
thought that HTML and CSS were meant to be softballs, for people who are geeky
but maybe not full-fledged programmers. HTML and CSS were the first languages
I learned, but my coworker stressed to me that they weren't full-on
programming languages.

> It’s 2018! All websites need to be responsive!

I wonder if responsiveness is another cause for this trend. I agree that
making pages that shrink and fold for various screens might put some novices
over the edge. But looking the simplicity of Julia's website, maybe all she
needs is a viewport meta tag.

Another advantage I've had is my lifelong interest in graphic design. Before I
knew CSS I knew about color, fonts, white space, etc. So I'm sure that made
learning CSS easier for me. But for those who aren't into that, why aren't
templates and stylesheets from other people enough? They've already chosen
fonts and colors and margins and stuff that looks good together. They give
classes for various kinds of pages and sections. Maybe you're somewhere in the
middle, where you're not adept enough to write your whole CSS from scratch,
but you want more customization than just using a general stylesheet. But why
can't you tweak it? If you're smart enough to use Tailwind, aren't you smart
enough to fiddle with some attributes in a stylesheet, make the corner
rounder, make a font bigger, etc.?

I truly am interested in understanding, if possible. CSS has a few things that
are mildly annoying, but just mildly. Nothing would ever make me want to do
something like this. Truly I am bewildered!

One more thing: my attention is spread across many complex applications,
thousands of lines of code, and I am in charge of the full stack (JavaScript,
HTML, CSS, PHP, Apache, SQL). So it's not like I get to spend all my time
focused on the front end. Yet my users have told me that my pages look nice.
I'm spread thin, but I've never wanted to use anything but stylesheets, no
BEM, no SASS, just good, old-fashioned selectors.

------
PavlovsCat
I always liked to mix both, having somewhat "semantic" classes like
_.message.error_ , but then also things like

    
    
        .w100 { width: 100%; }
        .nopad { padding: 0; }
    

etc. to modify the "semantic" classes where needed, in essence creating a
mini-framework for every new project.

