Tailwind CSS

A utility-first CSS framework for rapid UI development

#3 Product of the DayNovember 01, 2017

Tailwind CSS is a Utility-First CSS Framework for Rapid UI Development ⚡️

Discussion
Would you recommend this product?
68 Reviews4.8/5

I was able to use the pre alpha of Tailwind to build out my latest redesign of my personal site and it’s really incredible to work with. I’ve been talking with a adam for years about utility classes and it took a long time for me to come around, but I’m now in love and I think Tailwind is definitely the best of the bunch.

First, it's a utility framework. You're composing your CSS quickly, in the DOM, from really impressive defaults that the Tailwind team has worked hard to perfect--including working with a designer, Steve Schoger, who's tried all the defaults in multiple UIs to test them out.

Second, it's configurable. Pass Tailwind a configuration file and all of a sudden it's *your* colors, your fonts, your spacings.

Third, it's modern. The build stack and the way it generates its CSS is something the team has paid significant attention to, starting in Less and moving now to PostCSS. I was able to pick Adam's brain about how he made it work on his podcast: http://www.fullstackradio.com/71

Tailwind is really powerful. It's fast. It's flexible. I'm a *huge* fan.

Pros:

It make CSS simple

Cons:

The only con I know is that it’s still pre 1.0

Upvote (26)Share
👋 Hey everyone, maker of Tailwind CSS here! Thanks for hunting us @djug! Tailwind was born out of the frustration of trying to use frameworks like Bootstrap or Foundation to build sites that looked completely different than the defaults those frameworks provided. Instead of providing an assortment of higher level UI components like buttons, forms, cards, etc. all with baked in visual design decisions that you have to constantly fight to change and undo, Tailwind provides extremely low-level utility classes that you can use as building blocks to compose more complex pieces of UI. There are other "functional" or "atomic" CSS frameworks out there (Tachyons, Basscss, ACSS), so here's what I think makes Tailwind unique and why it was worth building: - Tailwind is highly customizable, and the customization story is a huge part of the framework's identity. Tailwind is implemented as a PostCSS plugin, and configured in JavaScript. You have full control over your color palette, type scale, spacing scale, box shadows, border sizes, etc., and *how* you customize all of that stuff is heavily documented and very first-class in the framework. - Tailwind uses a very human approach to class naming vs. the incredibly abbreviated and dense naming you see with a framework like Tachyons. That's not to say it's objectively "better", but it's a different and some folks will prefer that. - Tailwind doesn't demonize component classes. We don't think `.btn` is an anti-pattern, and we give you tools to make it easy to extract classes like that along with recommendations on when to do it. If this sounds interesting to you, definitely check out the documentation (https://tailwindcss.com/docs/wha...) and please hit me with any questions you have!
Upvote (16)Share
I would like to hear a comparison with Tachyons CSS (http://tachyons.io) which is also a famous utility CSS library!
Upvote (11)Share
@paramaggarwal I'd like the same thing. We used Tachyons to build www.cntr.al and one of my biggest dislikes was all the abbreviations it used that you had to memorize. Things like borders: Tailwind looks like it uses more verbose class names, like `.border-b-4` for bottom border of width 4px, which is more explicit and much easier to comprehend in the long run.
Well-documented library which stems from others like http://tachyons.io and (my team's) http://tedconf.github.io/shed-css/ I'm certainly in agreement with this CSS methodology, but I think tailwind has a couple of areas that could be improved upon: 1. The [very first example](https://tailwindcss.com/docs/wha...) shows a couple of different ways of declaring the size "value": - `max-w-sm` - `h-16` on the first one, `sm`, this can mean a number of different things at different times: – `max-w-xs`: Set the element's maximum width to 20rem. – `text-xs`: Set the text size to .75rem (12px). – `shadow-md` (xs and sm don't exist here?): Apply a medium box shadow to an element. This inconsistency leads to addition cognitive load for developers as they have to remember which options are available on each size and what that size actually corresponds to. 2. Rather than _encouraging_ users to "extract components" (https://tailwindcss.com/docs/ext...) in the css layer, consider pushing that to the user's templating layer! Abstraction-free CSS remains up-to-date and becomes one less thing that future-you needs to "check" or "update".
@vinspee Hey Vince thanks for the detailed feedback, I love what you and your team have done with Shed CSS, we've definitely taken inspiration from your work! Some thoughts on your points: 1. The sizing scale stuff is a really tricky problem. Some frameworks try to take a really machine-like approach to this sort of thing, valuing consistency above all other concerns, but we chose to make a different choice with Tailwind. Here's the general thinking behind the scales we use: Numeric scales are always consistent with each other, and are proportional. `.m-8` is twice as much margin as `.m-4`, and each unit is `.25rem` by default and that's consistent across all utilities that use this scale. For helpers like `max-w-{size}`, we started by using the numeric scale but it just became extremely unusable. The use case for those helpers is generally constraining areas of a layout, maybe something like a sidebar width, or the width of a login form. Using a numeric scale, a 40rem max width becomes `max-w-160` which maybe seems fine at first, but you quickly start to get lost when you don't know what values exist in the scale. If 160 is too big, what's the next size down? Is there a 148? Maybe the next one isn't until 120? We didn't want to make the numbers mean something different for different utilities, so instead we opted to just switch the scale to simple named sizes like "sm", "md", "lg", "xl", etc. This made it easy to know what the next size up or down was, because you never had to worry about gaps in the numbers. Named scales like this are always specific to each utility, so `max-w-lg` isn't going to be the same size as `text-lg`. This ended up being the right choice for us and makes the framework feel a lot easier to use in practice, even if it looks inconsistent at first glance. 2. I think a lot of people in the functional CSS community underestimate how many people are working on projects where they don't have a powerful templating engine. Tons of people are just building Wordpress themes; they don't want to turn a single HTML element with a single class like `` into a React component or a Twig partial. I totally agree that there's more than one way to skin the cat when it comes to creating abstractions around repeating utility patterns, but I don't think templatizing every piece of markup in a project is the most practical way to go for every single project. Thanks again for your feedback and for your awesome work on Shed!

There should be a separation of between structure (HTML), styles (CSS) and interactions (JS). By embedding these classes into HTML, you're basically tying the styles into the structure. This makes your site less modular - if you want to switch to a different framework later, it's much harder - you have to remove all the utility classes from the HTML.

This problem is not just specific to Tailwind however, all CSS frameworks (be it utility or UI frameworks) that places presentational classes in the HTML shares the same issue. I have explained how to resolve it here - https://stackoverflow.com/a/2882...

If Tailwind has Sass support, it would definitely be very useful.

Pros:

Less opinionated that Bootstrap, provides more flexibility

Cons:

Binds you to the framework, not semantic

Adam made a screencast were he demoed using Tailwind. There's one part where he talks about creating components, and I think it's similar to the solution you linked to in Stack Overflow. Here's a link where he starts extracting some of the utility classes into component classes: https://youtu.be/ZrRRMBaz5Z0?t=4...