Tachyons: 490 color combinations, one stylesheet, and no way to prune it

490 color combinations on an 8px baseline grid

Tachyons starts from a mobile-first architecture and an 8px baseline grid, so spacing and sizing utilities are multiples of one base unit instead of values picked per component. Color arrives as a counted set: the project claims 490 accessible color combinations, arranged so a foreground and background pair can be named directly rather than assembled in a stylesheet. The design lives in the markup, which is why the project states that CSS should not impede accessibility or the default functionality of HTML, and why the responsive grid is described as infinitely nestable. None of that count is a contrast audit you can read. No per-pair ratio, no WCAG level and no test result appears in the README, so if your review process needs a documented contrast value for a specific pair, you have to measure it yourself before shipping it. The debugging utilities meant to reduce layout struggles are also left unnamed, so you learn their names by reading the built stylesheet or the docs site rather than from a list.

The build pipes src/tachyons.css through the tachyons CLI

Local use starts with a clone and an install:

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

The scripts in package.json turn src/tachyons.css into the two files consumers load. build:css writes css/tachyons.css, build:minify writes css/tachyons.min.css, and build:watch reruns the build on every change under ./src/. Four entry points matter:

npm start
npm run build
npm run mutations
npm run build:watch

npm start is an alias for npm run build:watch, so the watch path is the same either way, and the modules in src/ are meant to be small enough to edit by hand. The toolchain behind them is small and dated: devDependencies pin tachyons-cli ^1.3.2, immutable-css-cli ^1.1.1, watch ^1.0.2, copy-files ^0.1.0, normalize.css ^8.0.0 and tachyons-modules ^1.1.10. package.json declares no engines field, so nothing states which Node version the build expects. When npm install or npm start fails on your machine, the README does not write down failure modes.

package.json resolves main to a stylesheet, not a script

package.json sets main to css/tachyons.css and style to css/tachyons.min.css, and the files array publishes only css and src. A package manager therefore gives you two stylesheets and a source tree, and nothing else. There is no JavaScript entry point, so a bundler that resolves the package main resolves a .css file rather than a module, and the project says nothing about which loader or configuration handles that case. Tools that read style receive the minified build while tools that read main receive the unminified one, and you do not choose which path a given tool takes. The limit shows up the moment you want to change the framework instead of use it: there is no exported scale object, no theme call and no runtime configuration, because there is no runtime. Changing the palette or the grid means editing files under src/ and rebuilding with npm run build, so plan for that before you depend on a custom brand color, since nothing in the package accepts one at build time.

The mutation linter only reads the src directory

The project ships a check for redefined or mutated classes, and the command is:

npm run mutations

The scripts section expands that to immutable-css src/tachyons.css --strict, so read the argument closely. The linter takes one file, the entry stylesheet, and asserts that each class in it is defined exactly once. The README positions this as a collision check for people who also load another library or write their own CSS, but the command as written has no access to either. It cannot report that a Tachyons class name is also defined in your stylesheet or in another framework, and it stays quiet when your own rule wins the cascade by source order. The practical consequence is that the linter proves Tachyons is internally consistent and stops there. Cross-library collisions remain your problem: you still have to compare class names by hand and decide which stylesheet loads first.

The CDN snippet pins a major version and nothing else

The quickest path to a working page is one line in the head:

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

The version reference is @4, a floating major tag, so the bytes you receive are whatever that tag resolves to on unpkg at request time. The release history does not explain how the two numbering lines relate. The newest tag is v0.2.1 dated 2026-07-20, the same day as the most recent commit, while package.json still carries version 4.12.0, and the entries below them are 4.9.1 from 2018-01-01 and 4.9.0 from 2017-10-26. What that costs you is reproducibility. A page whose markup says @4 records nothing about which release you tested, and a tag that follows the newest release in its line means the CSS behind an unchanged URL can differ from the CSS in your notes. If your build needs a fixed artifact, pin an exact version in the URL yourself and diff it against what you already ship.

Every utility ships, because nothing prunes them

The feature list advertises a lightweight sheet of roughly 14kB optimized for maximum gzip compression, and the file the CDN snippet loads is the whole minified build. There is no purge step in the build scripts and no configuration file in the repository that lists which classes a project uses. The code sent to the browser is therefore the entire scale, palette and grid rather than the subset your pages reference. On a small marketing page that is irrelevant; on an application with hundreds of routes it is bytes you pay on every uncached request. The single-purpose class structure cuts both ways here as well. Because the design lives in class attributes, correcting a spacing decision means editing markup across templates instead of one selector, which greps easily and drifts quietly at scale.

The docs live in a separate repository

Documentation is not part of this repository. The site sits at http://tachyons.io/docs, the source lives at https://github.com/tachyons-css/tachyons-css.github.io, and you can clone that repo to use as a template for documenting your own design system, patterns or components. The top-level entries of tachyons-css/tachyons contain no docs directory, so reading documentation costs a second clone or a page load. Component documentation generation is partly automated and partly manual, and the project says so with a plain note that not everything is automated. Three community resources sit alongside: a Learn Tachyons course repository from DWYL, a Tachyons TLDR class lookup at tachyons-tldr.now.sh, and Tachyons Pro, a quiz for memorizing class names. None replaces the stylesheet itself.

A master-branch link and an unexplained llms.txt

The repository is small enough to read in one sitting. Its top-level entries are .gitignore, .npmrc, README.md, code-of-conduct.md, css/, index.html, license, llms.txt, package.json, sites.md and src/. Two of those files are never explained. llms.txt sits at the top level with no description of its contents, and .npmrc is present with no comment on registry or install configuration, so a clone intended for studying the build ships files whose purpose the project never states. The contributing path is thinner still: the README points contributors at code-of-conduct.md on the master branch while the default branch is main, and no CONTRIBUTING file appears among the top-level entries, so a first-time contributor cannot rely on that link to reach the file and has no stated workflow for proposing a change. A longer list of production users lives in sites.md, with npmjs.com, gitpoint.co, play.cash and bitmidi.com among the featured entries.

Editorial conclusion

Tachyons suits teams that want a mobile-first utility layer with a build they control, and it suits badly anyone who needs pruning, runtime theming, or a release they can prove. Before adopting, pin an exact version instead of the @4 tag, expect to edit src/ rather than configure a theme, run npm run mutations after each source change, and measure contrast for the specific pairs you ship, because 490 is a count and not an audit.

Frequently asked questions

Official sources

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