Tachyons: functional CSS classes you paste into HTML instead of writing stylesheets

What Tachyons replaces, and who ends up using it

The README states the goal plainly: quickly build and design new UI without writing CSS. Each class does one thing, so a button's padding, color, border radius and hover state are separate classes applied in the markup rather than a .button rule in a stylesheet. The stated principles back this up, including that it should be easy to change any interface or part of an interface without breaking any existing interfaces. That is the actual selling point. You are not buying a component library with opinions about what a card looks like; you are buying a vocabulary.

The audience is narrow but real. Teams that ship server-rendered HTML, or JSX in React, Ember, Angular or Rails (the README lists these), get the most out of it because the class list lives next to the markup that uses it. Designers who work in the browser also fit, since the README lists designing in the browser as a principle. Teams with a heavy design-token pipeline and a component library of their own will find Tachyons competes with that pipeline rather than feeding it.

How the class system is put together

Tachyons is built with PostCSS. The repository ships a src directory and a css directory, and package.json points main at css/tachyons.css and style at css/tachyons.min.css, so consumers of the npm package get compiled CSS rather than source. The build pipeline is three npm scripts: build:css runs tachyons src/tachyons.css > css/tachyons.css, build:minify runs the same input with --minify into css/tachyons.min.css, and build:watch wraps both in a watcher over ./src/.

Two properties in the README matter more than the class count. The first is the 8px baseline grid, which means spacing utilities land on a consistent rhythm rather than arbitrary pixel values. The second is that the library is optimized for maximum gzip compression, which is why a large number of short, repeated class names can stay near 14kB over the wire. The README also claims 490 accessible color combinations and an infinitely nestable responsive grid, and lists multiple debugging utilities. Those are the features to check against your own design before adopting, because they define the ceiling of what you can express without adding your own CSS.

Installing Tachyons and styling a real element

The fastest path in the README is the CDN. Paste this link tag into the head of an HTML file and the minified stylesheet loads from unpkg, with no build step and no npm install.

<link rel="stylesheet" href="https://unpkg.com/tachyons@4/css/tachyons.min.css">

If you want the source and the build tooling, clone the repository and install dependencies. The README gives exactly these three commands.

git clone https://github.com/tachyons-css/tachyons.git
cd tachyons
npm install

From there, npm start compiles minified and unminified CSS into the css directory and watches src for changes. It is aliased to npm run build:watch. If you only want a one-off compile, npm run build does it without the watcher.

npm start
npm run build

After npm start, edit a file under src and the css directory updates. The README notes the modules are generally small and quick to read, so opening src/tachyons.css is the intended way to learn what a class does before looking it up in the docs at tachyons.io.

The mutations linter, and the collision problem it admits to

The most interesting script in package.json is not the build. It is mutations, which runs immutable-css src/tachyons.css --strict. The README explains the purpose: checking that a class has not been redefined or mutated, useful when you use another library or write your own CSS and want to make sure there are no naming collisions.

That script is an admission. Functional CSS works by putting many small, globally scoped class names into a shared namespace, and any other stylesheet that defines the same name silently changes every element using it. Running the linter is not optional hygiene for a large codebase; it is the only automated check the project offers for the failure mode its own design creates. If your existing CSS has classes like .f1, .pa3 or .mw7, expect the linter to report them, and expect to rename yours.

Where Tachyons is the wrong tool

The README does not document rollback, migration or deprecation policy, and the release history is uneven: v4.9.0 landed in October 2017, 4.9.1 in January 2018, and the next release in the list is v0.2.1 in July 2026, with the repository's last push on 2026-07-20. Anyone planning a multi-year dependency should read that timeline as it is rather than assume a steady cadence.

The design trade-off is sharper. Because every utility is global and single-purpose, there is no natural place to change the meaning of a spacing step or a brand color across a product. Changing the 8px scale means editing src and rebuilding, and every file that depends on the compiled output picks up the change at once. Teams that need design tokens centralized, themed at runtime, or scoped per component will spend their time fighting the model. The same applies to markup volume: a heavily styled element accumulates a long class attribute, and that cost is paid in every template that renders it.

Tachyons against a utility framework with a config file

The closest comparison is Tailwind CSS, which also ships single-purpose utility classes but takes a different route to the same place. Tailwind generates its stylesheet from a configuration file, so the spacing scale, colors and breakpoints are declared in one project-owned file and the utilities are produced from it. Tachyons ships a fixed, pre-built set of classes; the README's own framing is that you clone the repo, edit src, and rebuild if you want different values.

The practical difference is where customization lives. With a config-driven generator, changing a color means editing one file and regenerating. With Tachyons, it means editing the source modules and running npm run build, then distributing that build to every consumer. That is simpler for a small project that accepts the defaults and heavier for an organization that needs its own scale. Tachyons also predates most of the current utility-framework tooling, and its README points to community resources such as DWYL Learn Tachyons, a class lookup at Tachyons TLDR, and a quiz at Tachyons Pro rather than to a plugin ecosystem.

Licence and the cost of staying current

Tachyons is MIT licensed, stated in package.json and in the license file at the repository root. That permits commercial use and modification, and the practical implication for a fork is that you carry the copyright notice and licence text with the code you redistribute. This is a description of the licence text, not legal advice; check it against your own distribution model.

The upgrade cost is mostly a rebuild. The package publishes css and src as its files array, main points at css/tachyons.css, and style points at css/tachyons.min.css, so a project consuming the npm package depends on the compiled output rather than on the source. If you fork src to change the scale, you own the merge on every upstream change. The mutations linter is the one command worth wiring into CI, because a class collision introduced by a dependency will not surface in a build that only compiles CSS.

Editorial conclusion

Adopt Tachyons when the markup is the design surface and you want a fixed, documented set of classes rather than a growing stylesheet. Do not adopt it if your team needs design tokens centralized in one file, or if you expect component-level encapsulation; Tachyons classes are global by construction and the mutations linter exists precisely because collisions happen. Before committing, run npm run mutations against your existing CSS to see how many of your class names clash with Tachyons, and read src/tachyons.css to confirm the scale and color combinations match your design.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tachyons-css/tachyons on GitHub