the smallest, fastest, most feature complete Tailwind-in-JS solution in existence
If you are here then the likelihood is that you using Tailwind or a CSS-in-JS solution such as styled-components, emotion or goober in order to style your web applications. These packages have proven overwhelmingly popular and revolutionized web development as we know it.
The purpose of this project is unify these two approaches; embracing the flexibility of CSS-in-JS whilst conforming to the carefully considered constraints of the Tailwind API.
We hope to create a place for likeminded people to discuss issues, share ideas and collaborate.
If you would like to get started with twind right away then copy paste this code into your favorite sandbox.
📚 For more detailed instruction on usage please read the documentation.
import 'https://cdn.skypack.dev/twind/shim'
document.body.innerHTML = `
<main class="h-screen bg-black font(bold sans)">
<h1 class="text(sm:red-500 md:white lg:blue-500)">This is Twind!</h1>
</main>
`Alternatively try the live and interactive demo.
This project was started by the authors of two similar libraries – oceanwind and beamwind – who chose to collaborate rather than compete with each other in this space.
Combining efforts has saved us time and resulted in a much more complete and production ready offering.
Furthermore we were able to agree on and coin some standards for certain aspects of the implementation based on our collective learnings; things like parsing input, grouping syntax, prescedence calculation and plugin API.
A lot of developers ask "Why not just use Tailwind?" and our answer is always that you should use Tailwind, it is an absolutely incredible API with amazing documentation!
I've wanted to do a CSS-in-JS flavor of Tailwind for over 2 years because of all the neat benefits you get there so it's cool to see projects like this! – @adamwathan
However, if like us you are already building your app in JS using a framework like react, preact, vue or svelte, rather than just static HTML, then compiling Tailwind shorthand just in time (like twind does) rather than ahead of time like with Tailwind and PostCSS, comes with a lot of advantages.
⚡️ All setup is done almost instantly at runtime, no build step required
In fact, there is no dependency on Tailwind or PostCSS at all. This makes that is possible to reconfigure the compiler on the fly and apply new themes without rebuilding anything.💸 Unlimited styles for a low fixed cost of ~10KB
By shipping the compiler (rather than the resultant output) there is a known and fixed cost associated with styling. No matter how many styles you write or how many variants you use, all your users will ever have to download is approximately 10Kb of code (which is less than styled-components or your average Tailwind build).✈️ Includes a themed Tailwind preflight stylesheet by default
The [base reset](https://tailwindcss.com/docs/preflight) provided by Tailwind is instantiated with respect to your theme (values like fonts, colors etc.) and injected in the stylesheet during setup. This guarantees more consistent cross browser results out of the box.
❄️ Optional hashing of class names ensuring no conflicts
By default no hashing is enabled to aid debugging during development. However it is possible to configure Twind to [hash class names](https://github.com/tw-in-js/twind/blob/main/docs/customization.md#hash) before injecting them into the DOM. This may be useful in production as it can reduce the down the wire size of server side rendered pages pages and eliminates any chance of class name conflicts with third party styles.🎢 Familiar and Tailwind V2 compliant theming
Theming is done exactly as [documented by the Tailwind](https://tailwindcss.com/docs/theme) meaning that you can copy paste in your themes from existing projects. The only different here is that there is no need to rebuild anything after changing you theme. Just refresh the page!🤖 Built in support for conditionally combining rules
Input is not limited to strings like with HTML classes. The Twind function accept arrays, objects, template literals, functions, almost everything! The interpretter spec is inspired by and very similar to [clsx](https://github.com/lukeed/clsx) and offers a much more developer friendly API that handles null values gracefully.🌈 Improve readability by breaking rules over multiple lines
Using template literals as input ([the recommended method](https://github.com/tw-in-js/twind/blob/main/docs/usage.md#template-literal-recommended)) or even object syntax allows you to break rules over multiple lines, drastically improving readability and maintainability of complex rules.🎯 Custom syntax for grouping directives and variants
Having control over the interpreter affords us the possibility of defining terse syntax for [grouping responsive and pseudo variants](https://github.com/tw-in-js/twind/blob/main/docs/grouping.md) as well as directives with common prefixes. This massively reduces repetition and improves comprehension.🚓 Escape hatch for writing arbritary styles
The compiler [accepts functions](https://github.com/tw-in-js/twind/blob/main/docs/usage.md#inline-plugins) that can return arbritary CSS-in-JS objects. A convenient a escape hatch for all those one off rules which aren't supported by tailwind. The `&` keyword allows you to write complex rules (like pseudo elements `&::before` and `&::after`) that are beyond the scope of inline styles without having to add another dependency.🚅 Faster than all popular CSS-in-JS libraries
Given the limited grammar that the compiler has to support there is a much higher chance of finding a rule and its variant in the cache, because of this along with some other specialist optimizations we are able to compile and inject CSS faster than all the popular CSS-in-JS solutions.🔌 Language extension via plugins
Extending the grammar is trivial and can be achieved by providing functions _inline_ or by generalizing inline rules and defining them during setup under [the _plugins_ key](https://github.com/tw-in-js/twind/blob/main/docs/plugins.md).🎩 Remove all runtime overhead with static extraction
The compiler itself is not reliant on the DOM at all which makes it an ideal candidate for static extraction which essentially removes all runtime overhead. This is possible during SSR or build time prepass.🧪 Generate styles for stringified markup
It might not always be desireable to generate rules by invoking the compiler direct via function call. In this case you may use the shim module which finds and replaces class names within static HTML, generating styles appropriately. This is especially useful during developemnt too; for example when editing classes in the inspector.The following snippet demonstrates typical usage of both the tw and setup functions:
import { tw, setup } from 'https://cdn.skypack.dev/twind'
setup({
preflight: true, // Include Tailwind base reset
theme: {
extend: {
colors: { hotpink: '#FF00FF' },
rotate: { 5: '5deg' },
},
},
})
body.innerHTML = `
<div class='${tw`
h-full
flex items-center justify-center
bg(hotpink burple-500 green-500)
`}'>
<h1 class='${tw`
text(white 4xl)
font(bold sans)
transition-transform
hover:(rotate-5 scale-150 cursor-pointer)
`}'>Hello World</h1>
</div>
`The implementation is tested for speed alongside several popular CSS-in-JS solutions that export general css functions. For those that only support a styled component approach an equivalent test has been setup. Currently Twind is the fastest in both scenarios in part due to optimal caching of static parts from template literals.
twind x 403,080 ops/sec ±1.41% (88 runs sampled)
[email protected] x 143,202 ops/sec ±0.90% (95 runs sampled)
[email protected] x 224,368 ops/sec ±0.52% (93 runs sampled)
twind x 51,628 ops/sec ±0.63% (89 runs sampled)
[email protected] x 40,069 ops/sec ±0.43% (96 runs sampled)
[email protected] x 35,349 ops/sec ±1.01% (93 runs sampled)
[email protected] x 38,284 ops/sec ±0.48% (93 runs sampled)
For a more detailed testing summary please see the benchmarks directory.
It would be untrue to suggest that the design here is totally original, other than the founders initial attempts at implementing such a module (oceanwind and beamwind) we are truly standing on the shoulders of giants.
- tailwind: created a wonderfully thought out API on which the compiler's grammar was defined.
- styled-components: implemented and popularised the advantages of doing CSS-in-JS.
- htm: a JSX compiler that proved there is merit in doing runtime compilation of DSLs like JSX.
- goober: an impossibly small yet efficient CSS-in-JS implemetation that defines critical module features.
- otion: the first CSS-in-JS solution specifically oriented around handling CSS in an atomic fashion.
- clsx: a tiny utility for constructing class name strings conditionally.
- tiny-css-prefixer: essentials CSS prefixing helpers in less than 1KB of JavaScript.
- csstype: providing autocompletion and type checking for CSS properties and values.