Travis Dunn
Apr 4, 2017 · 5 min read

Our Path to MVP: Tachyons

Being a technical founder ain’t always easy. You have to balance your technical side that wants to play with the latest and greatest technologies, as well as the practical side that wants to build things quickly and efficiently. It’s not always an easy balance to achieve, but it is critical for the early MVP stages.

I wrote on a previous post about why we chose Rails for our stack at WorkWeek. Now I wanted to cover why we chose Tachyons. I’ll do my best to cover what we’ve learned, how we implemented it, and the pros and cons we’ve found.

First off, a bit of background. I’m mostly a server-side developer–I’ve been doing development long enough to remember when there wasn’t really a distinction between front-end and back-end, but when things started to split I found myself moving more towards server-side work. I’ve had the pleasure of working with some brilliant front-end devs–members of the jQuery core team, contributors to React, and many other brilliant folks. I’ve always listened, learned, and generally paid attention to what is going on in front-end land.

When we started WorkWeek, we started as a really small team. I was heading up most of the development, and I had to make a decision about how to handle the front-end. I asked some of my front-end friends, and I kept hearing about Tachyons. At first glance it seemed like “another bootstrap”, but as I began to look into it, it became clear that it really wasn’t anything like Bootstrap. The Tachyon’s homepage reads:

Built for designing.

Create fast loading, highly readable, and 100% responsive interfaces with as little css as possible.

It is highly readable (and there’s often a lot to read), and it does leave you with very little css to write, but more importantly, it almost always does what you expect. It’s a very different way of thinking about doing markup and css–somewhat of a cross between inline styles and traditional css class based styling. What it basically means in practice is that you should be able to look at the markup and figure out what css styles are applied, and how the element is going to look. That might not sound different from traditional css, but it is.

Traditionally you might see a link with a class of btn. You might know from the classname that it’s a button, and maybe you only have one button style, so you know how it’s going to actually look. However, as projects grow you’ll end up with .callout-btnor maybe you’ll style it using .a-div .btn. It can get confusing knowing what class does what, and if you need a button that’s sorta like the other one but with a slightly bigger font-size, you’ll need a new btn-large class or a new selector. With tachyons buttons might look like this:

<a class="f6 no-underline dim br3 ba bw1 ph3 pv2 hot-pink" href>Button Text</a>

Now either that markup will disgust you, or you’ll be intrigued–either way, hang with me for a bit longer. If you read the class list, you can pretty much figure out every style being applied.

  • f6 sets the font-size using the Tachyons type-scale
  • no-underline removes the default underline on links
  • dim will animate opacity on hover
  • br3 sets the border radius
  • ba sets border all
  • bw1 sets the border width
  • ph3 sets the horizontal padding
  • pv2 sets the vertical padding
  • hot-pink sets the color to hot-pink

All of those classes will render this:

Image for post
Image for post

A lot of the Tachyons classes have numbers, they’re based on a Tachyons scale which rely onrem units. Everything is sized and scaled proportionally to stop you from making bad design decisions. Again, what this means is that 99% of the time, everything words as expected and requires very little thought. It also means that code can be moved almost anywhere and it’ll render the same. Need a new look for a different page, just tweak the class list.

That’s the basis for how Tachyons works–everything is done through classes. From setting the cursor and z-index, to floating, and absolute positioning–it’s all done through individual classes. You can write zero css and implement a design, or treat it more like bootstrap and freestyle something that looks decent. There are other great benefits too. The grid system, responsive, debugging classes, the color pallete, etc.

Tachyon’s also has a useful components page that shows various ways to implement common components/layouts/styles. It’s pretty much copy/paste and tweak, which is all part of benefit of having the classes be so descriptive.

The beauty of Tachyons is in the simplicity and explicitness of what it does (and doesn’t) do. If you’re not convinced, it’s probably safe to stop reading.

How do we use it in Rails?

Pretty straight forward. Tachyons has an official sass version. You can implement it directly by copying it into lib/assets (or wherever you prefer). There’s also a rubygem tachyons-rails that will handle it for you.

We do overload some color variables to match our brand–which is straightforward with sass. Other than that, we set it and forget it.

What about Bootstrap?

Bootstrap is great for a lot of things. I’ve found that when I use Bootstrap I end up fighting with it more than benefiting from it. Bootstrap themes help, but usually you can still tell when a site is Bootstrap, because the styles are somewhat forced and predictable. Tachyons forces you to pick individual styles (border width, font-size, etc), which gives you more overall control. If you don’t need that, Bootstrap might be the better choice.

Final thoughts

I can honestly say that we wouldn’t have launched when we did if it weren’t for Tachyons. For me it was largely not being allowed to overthink style decisions. Tachyons having limited options for font-size, padding, margin, positioning, and even colors all take a lot of the weight off. But still being allowed the freedom to put all of those pieces together to implement a design that’s on-brand. It also goes a long way knowing that all of the options were meant to work together in a design system, again saving time and mental overhead.

I did spend a fair amount of time trying to figure out ways to not have big class lists. I’ve learned to go with the flow here and just embrace them mostly. Where we did standardize was on form inputs, we extended the Tachyons classes on our inputs because they’re all styled the same.

It’s also worth mentioning that if you decide to change something across the board, like say a button style… and you didn’t make a class that wraps those styles up, it’s gonna be a slow painful process to change all of those buttons–especially if you didn’t consistently order your classes so you can do a convient find and replace.

One nice benefit that you’ll get if you work with teams, and/or junior level devs is that there’s a style guide–the Tachyons docs (which are really great). Ideally they wont be writing css, they’ll be using Tachyons, so you can point them to the docs and they can get to work.

All in all, I’ve been happy with Tachyons, and it’s a great practical tool to have in the toolbox. If you haven’t given it a look, it’s different enough that it’s worth a glance.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store