Tachyons, the best library you're not using.

Pim Brouwers on December 05, 2018

My professional focus hasn't been on front end development for quite some time. However, since I tend to work solo on most of my data-oriented proj... [Read Full]
markdown guide

I'm a big fan of Tailwind (tailwindcss.com/) - similar to Tachyons but better imo.

I'd recommend this video to anyone interested in why you should switch to utility-first CSS -> dotall.com/sessions/a-real-life-jo... (a talk given a couple months ago by a friend of mine).


I'm used to writing CSS using SCSS, mixins, and namespaced stored values, completely avoiding magic numbers.

The level of abstraction offered by TailwindCSS is very close to writing inline CSS, using "chunks" of properties vs. individual properties. With the drawback of having to learn a proprietary API.

I can see how it avoids the overhead of naming things but feels extremely verbose and repetitive to me.


Chunks of properties are way more composable than properties themselves. And the overhead of naming can be huge... Especially in a larger project. And changing the css in larger projects can be a nightmare, so it rarely gets changed and instead after each new feature a specific chunk of css gets added, leaving the rest of the css unchanged out of fear. Otoh sprinkling chunks in your html, i.e. building properties out of chunks, rarely forces you to write new css (which also means that your css won't grow). And finally with inline css you can't use media queries or pseudo classes and if you tried it it's way more verbose than a dozen of class names.


Can you explain how this is different from literal style attributes in the markup?
I guess it is slightly more concise and easier to write, but I feel like this would still make the markup enormous?
Inheriting from these classes for your actual component classes in a preprocessor seems like a better use for this library.


Mihail, we meet again!

I can explain the difference. Inline styles and this methodology are different for a few main reasons.

  • Inline styles can be any value or property, leading to inconsistencies in padding/colors/etc
  • Inline styles complicate specificity, and are not responsive
  • Inline styles do not get cached, whereas your atomic classes would on subsequent pages

In terms of readability, there are ways to make it easier. For example, people think atomic css always has to be this:

<div class="container">
    <p class="text-black text-16 font-600">Blah</p>
    <p class="text-black text-16 font-600">Blah</p>
    <p class="text-black text-16 font-600">Blah</p>
    <p class="text-purple text-16 font-600">Purple Blah</p>

When in reality, I would do it like this:

<div class="container text-black text-16 font-600">
    <p class="text-purple">Purple Blah</p>

Also, take a look at large-scale website, open up their minified CSS, and see how many times they duplicate properties like display: block or display: flex. It'll blow your mind how many times they redeclare properties like this.


Inline styles can be any value or property, leading to inconsistencies in padding/colors/etc

Yes, but what happens when your library has text-16, text-17, text-19...?

Inline styles complicate specificity


, and are not responsive

That is so true!

your atomic classes would on subsequent pages

But their use isn't cached, it's in the dynamic markup.
Sidenote: Yes, I know the pre-parsed css has better performance. Yes, I know there is a performance advantage when your markup is generated on the client vs actually doing inline styles for all the nodes in JS

<div class="container text-black text-16 font-600">

Couldn't you just put the inline text color up on the div as well?🤔

duplicate properties like display: block or display: flex

You mean duplicate them where they were already applied? Because that's a sign of having no idea what they're doing.

Whereas if by duplicate you mean it is a property of a thousand classes, that is to be expected, they might have a thousand different flex container components.


I had the same experience, with tailwind. I used it only in small side projects, as for work I still rely on f6.

It definitely covers 90% up of css, and removing a constant rebuild of my sass it saves time over medium long term.

I see there are some differences, like default presets, namings. Is there some other major difference? Tachyons is ~10kb, while tw is ~60, is it just because the 50 colors of default?


I've actually never heard of tailwind, I'll check it out. From a quick glance it seems it might be the smaller class names (tachyons is abbreviated in almost all cases .ma3 for margin: 1rem; contributing to the lower bundle size.


Definitely implement purgecss to remove the unused classes from your completed markup, and you'll have only what you need!


Agree on all accounts. I researched this library and loved it, but didn’t end up picking it for a project just because other things came up.

Seems super top notch.


Great feedback. Feels great knowing a smart person came to the same conclusion as me! I think I came across this at the perfect time in my development arch as I learn more and more about functional programming. Now if only we had a tachyons for email!


For me what happened was, I ended up creating my own functional CSS framework before I even knew the existence of tachyons or others. It seemed the natural evolution of doing fast, visually accurate, bug free, easily maintainable and extendable websites. I am ready to prove this to any disbeliever by a real life coding challenge any time/any day. The only reason this is not a standard is the dogmatism of some so-called "semantic" evangelists like Zeldman etc who would essentially be without a job without it. They spent years to convince everyone that every class name you choose has to "mean something" only to realize there was no real world business or technical value of having semantic class names in your HTML. ( because we already have aside,nav,main and soon will have web components).


Love the fire! Do you host the code of that library on GitHub? Would love to see your take. I started doing the same, but after a while it felt kind of like "why the hell am I doing this?".


I realised an interesting positive side-effect of using atomic classes: It forces you to make your markup DRY. Because if you have multiple elements that get the same let's say, 3-7 atomic classes, it gets painful very fast to repeat and maintain this repetition, so you realise when your markup isn't DRY.

code of conduct - report abuse