▲ 266 points
back
288 comments
That example also encapsulates everything that wrong with how CSS is used today.
The markup contains no information about what the contents are anymore, so you lose the ability to target anything that is X: for example an email, an avatar within a 'people-card' etc.
HTML/CSS was supposed to separate content from looks. Of course that ship has sailed long ago, since modern day development seems to be insistent and mushing HTML, CSS and JS together in the same file. Looks is logic is content is looks is a mess.
HTML/CSS was also supposed to be re-usable. Now instead the re-usability is within react/angular/etc. components, so you now have to use react and javascript everywhere you want to show similar elements - if you want to have the ability to easily change them later.
Of course this isn't the point. If you have the ability to work with react components, you probably are knowledgeable enough to use CSS.
So the only remaining use-case is "way for non-technical people to write objectively bad HTML and have it look nice".
Which again, is fine. Sometimes bad is good enough when the alternative is nothing at all.
I'm still not a fan.
Check out the Tailwind author's reasoning: https://adamwathan.me/css-utility-classes-and-separation-of-...
I find it more compelling than I expected.
The truth of the matter is that as much as the idea of separation of html vs css sounds good, it's so hard that I rarely see it done. Without constant vigilance, you end up with premature abstractions, things you can't actually reuse, and an append-only accumulation of CSS.
The dream sounds good but leaves all the hard details for you to work out yourself. And frankly, after over a decade, I remain unconvinced and ready to look for new ideas.
Breaking the rule with Bootstrap since it first came out never stopped me from building great things, yet trying to obey the rule slowed me down and had me constantly refactoring CSS. It feels like a cargo cult.
We've been pointing to CSS Zen Garden for 17 years as an example of the benefits, but giving everything a class so that you can address it from a .css file isn't the hard part, and that's all the garden shows. The hard parts are organization, maintenance, coming up with a unified strategy, playing CSS whack-a-mole when you change HTML, deciding where to define what, finding where you defined what, etc. The garden demonstrates none of that.
> HTML/CSS was supposed to separate content from looks. Of course that ship has sailed long ago, since modern day development seems to be insistent and mushing HTML, CSS and JS together in the same file.
As a developer, what incentive do I have to scrupulously maintain the separation between content and appearance? Users do not appear to demand it, and customers or employers will not demand it either - they might care if the users hassled them about it, but this does not happen.
> HTML/CSS was also supposed to be re-usable. Now instead the re-usability is within react/angular/etc. components, so you now have to use react and javascript everywhere you want to show similar elements - if you want to have the ability to easily change them later.
If HTML/CSS was supposed to be re-usable, then it might have been a good idea to have designed those languages to support the kinds of re-use that are actually needed. One of the useful features of Tailwind, for instance, is that it becomes possible to copy HTML from one page to another while preserving consistent appearance, because all of the information necessary to display the element is contained within the class names. With most CSS, this is not the case: styles will depend on complex selectors, such that an element may appear completely differently depending on its ancestor elements.
The brittleness of CSS leads to various hacks and abstractions, and it is these hacks and abstractions that make re-use difficult. In reality, CSS depends on the structure of the HTML to work properly, and HTML has to be structured to suit the needs of CSS. This makes it hard to write general-purpose CSS that can effectively re-skin a HTML page, and to write HTML that is easy to lay out in the desired manner with pure CSS. It just doesn't work well enough to make the dream of decoupled content/styling workable in enough cases.
> HTML/CSS was supposed to separate content from looks.
IMO the problem is that HTML is woefully inadequate for expressing the sort of content we have today on the web.
It’s a document container that we’ve shoe-horned an application platform into. Much of what is displayed on some of the most popular sites can’t even be described as “content”—it’s interface, and that’s where things fall down.
It’s hard to follow semantics when the only option you have is positioning and styling divs. In that regard the style becomes part of the content. Nested divs have no meaning, and there’s no way to give them meaning in the same way that <p> is a paragraph. Aria labels help on the accessibility front, but outside of that the only way to express meaning of something like a modal or a popover is visually.
You don't have to use React and JS to get components. You can still get components with server or build time rendered HTML. About the only time you can't is if you are writing html and css files by hand. If you have some kind of css preprocessing going on, you can still get there with Tailwind's @apply with hand written html.
Whether components are a good thing in this particular context is debatable. But you can create them without JS.
> If you have the ability to work with react components, you probably are knowledgeable enough to use CSS.
If you are building a webapp, nobody is knowledgeable enough to use css because css is broken for this use case. Tailwindcss is absolutely aimed at css experts. There is nothing for non-technical people in tailwindcss because it exposes all the existing css properties, just with a selection of values.
Please excuse if my questions seem rude, but I'm very curious:
1. How many UIs for websites / webapps have you written by yourself?
2. How many while working within a team?
I have a modest web UI dev experience myself and Tailwind doesn't seem that crazy to me. I've tried the techniques you seem to be advocating, but the idea of them sounded better than they actually were in practice.
If you're working on the content and the looks at the same time, and you don't 100% know where the project is going, it's helpful to consider them as a combined unit, so you can alter and/or discard that unit without delving into separate CSS and HTML trees. (Or, worse, not being sure what HTML or CSS you should alter or throw away when its corresponding CSS or HTML ends up in the garbage).
Separate content and presentation is a great final outcome, but when a project is in flux as it's being built, it's a burden.
EDIT: Moreover, it's not just that the "ship has sailed long ago"; the ship was attacked and sunk. Frameworks that combine CSS and HTML aren't doing so out of neglect; they're aggressively rejecting the separate looks/content paradigm.
I'm not a fan either. The always cited rationale does not click with me, it even pushes me more away from the concept.
For me it tells in short: "Well, you could have nice and clean semantic CSS if you created and followed a design doc. Use tailwind and cryptic classes that could be whatever in any other project, if you don't bother about design docs."
I believe things like tailwind make developers less knowledgable of their craft. This has a big advantage though - you can have more people doing code for you, they don't need to know CSS at all to some extent.
there is nothing stopping you from using @apply in custom classes if you really want to - or using data attributes for targeting, depending on your use case.
The discussions of Tailwind are always heated but fundamentally boring because all the threads are started by people making the obvious objections that arise before you use it which were answered by Adam three years ago.[1] Do people who have actually used Tailwind in a real project have anything to add?
[1] https://adamwathan.me/css-utility-classes-and-separation-of-...
For my part, I am seeing slow rendering on some of my sites (page doesn't appear on webpagetest.org until 1s after network is done), and I wonder if maybe having atomic CSS is slower to render? Anyone have experience with that?
Wasn't the whole point of CSS to separate presentation from data, and move away from <font color=red> and other <table> that made layouts too difficult to change? Consider this:
<h2 class="text-purple-500">Customer Support</h2>
How is this different from <h2><font color="purple">Customer Support</font></h2>? This is still considered bad practice, right?
Tailwind sounds like a crazy and backwards concept. It looks insane and I used to feel the same way. However, after trying it and it clicked I can't imagine myself going back. It's one of those things you really need to try before you get it.
Now I find all of these arguments against it like someone trying to convince me not to use syntax highlighting (http://www.linusakesson.net/programming/syntaxhighlighting/). I understand the reasoning but it's not something I would even consider.
This is why I don’t love Tailwind as much as I’d like:
"It gives developers without a deep understanding of design the ability to build visually gorgeous, modern user interfaces."
This is flat out a myth i widh people stop regurgitating. Look, unless you do css as your primary skill or really passionate about the more visual side of things (the "front of the frontend") then you don?t magically have the skills to use all kind of css layout te hniques to do precise and elegant UI, given the sketch / figma files. Heck most JS devs I’ve worked with barely understand how flex works. Best scenario they make somthing close to provided design, but not quite ... and crucially the finishing touches , the consistency , understanding of design principles that inform every layout you make is missing, so the end result is never quit3 what the designer provided with all kind of small but noticable imperfections like incorrect font sizes, une en spaces, missing white spaces, inconsistent vertical rhythm, relative sizes between icons and text etc etc.
Yes, tailwind is good. As a standard utility framework it?s awesome but please stop prentending it turns JS devs magically into css/html experts.
There's something to be said about being able to build out an entire component with just using your editor's css autocomplete. The name "tailwind" is really apt once you get the feel for it.
The authors did decide to 'fix' some css naming, such as Tailwind's `hidden` class is `display: none` rather than `visibility: hidden`, which seems wrong at first. But when you see that `visibility: hidden` is `invisible` in Tailwind, it does makes sense. I still can't help but think just following the existing naming might have been better, about my only teeny tiny gripe so far.
> This does require some design taste, but most frontend engineers I know have developed that over the years of building user interfaces.
Nope. Never really happened for me. Admittedly I don't solely work on frontend. But 22 years of making user facing interfaces and I really don't feel more confident about it than I did on day one.
I’ve been thinking about an alternative to tailwind but I have no idea how to implement it.
I think what would be even more powerful is you configure all the classes with some kind of regexp. They need to be unique. You could provide a function as well that returns the correct css for any given captured units in the class name so eg. "mb-4em" you have template "mb-(\\d+)em" declared. The tool recognizes it and either just puts the number there, uses a mapping (4 becomes 16), or calls a function to return the resulting css properties.
What I like about it is you could just as well create more advanced utilities and the parser never generates any classes in advance. It would need some kind of watcher though to detect any new class aded to templates that match the definition file.
Then there would be no need to purge anything. Kind of a vague concept I’ll admit, but for me starting with a figma or sketch where designer typically does not folow a consistent guideline, it means I can just start writing templates and keep declaring utilities as I go because in the real world you bet that happens.
Tailwind must have an extremely talented social media guy/growth hacker or be a very good product:
14 HN front-page hits within just one year.
https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...
Edit: Got downvotes, guess what haha
Not a fan of it myself. I've never understood this desire to avoid writing CSS wherever possible. It's not hard - at least not anymore - but this type of abstraction makes it hard, in my opinion.
On top of that, I think it's just a bad idea to pepper your html with utility class names.
That said, these days pretty much everything I do is React, and styled-components' ability to interpolate props in styles and attributes is pretty darn nifty.
Oh my god, it just keeps on getting worse!
Sure, let's take long strings of barely-scrutable utility classes and make them transform into CSS-in-JS statements under the hood via an overcomplicated build pipeline—WTAF.
What I find so ironic is pure, native, truly-modern CSS with properties/variables, Flexbox, Grid, encapsulation via Shadow DOM if you want it, etc. has gotten so-o-o-o good, you barely even need a framework anymore. Stuff like Tailwind feels like it's solving the problems CSS might have had…er, ten years ago.
Regarding performance, twin.macro seems like a fantastic approach for React users, inlining the styles where needed with Emotion/similar.
It also answers the "where do custom styles go" question to some extent (answer: the css prop).
https://github.com/ben-rogerson/twin.macro
Edit: I had stopped reading half way through! This is what the article is about. I'll leave my comment up to publicly shame myself.
I'm a really big fan of tailwind as someone who doesn't like to do frontend. It's let me iterate decent-looking proof of concept features and MVPs while focusing mostly on the backend, where previously most of my designs would look like craigslist.
One of the best things about Tailwind (and the component and HTML-first movements in general) is a move towards Locality of Behavior:
https://htmx.org/essays/locality-of-behaviour/
With these approaches, you can achieve a complete understanding of a component in one place, without needing to pick around in a bunch of different places, using id-matching or some other mentally burdensome mechanism to keep everything straight.
There are trade-offs (as the essay mentions) but Locality of Behavior obviously has a lot of advantages.
I like tailwind, but I just used it for small side projects so far.
Something I don't understand yet, is how you would use the "purgecss" feature in a large project or in the context of a company with several teams and a design system.
For example, let's say we have a shared React components library, which has been built with tailwind. Should this shared library expose an already built and purged css file?
Should each of our applications do its own purging? If so, how do I prevent the same m-1 to have two different values, one from the shared component library and another from my own application?
If I have to add node_modules/my-library to the purge directories... Wouldn't that still leave styles for components I might not be importing in my application?
Should I have a shared tailwind.config.js?
These are the things that worry me about using tailwind in a larger context than a small/single project.
Tailwind's paradigm ("atomic css") is great and the future, but there is a much better implementation, the barely maintained Tachyons is way superior and was also the first that made atomic css popular. I wrote following on Reddit which still holds true:
After 2 days of testing, I chose this stack:
Tachyons as primary CSS-in-JS and media-queries method in my React components; why: it's slick, easy and complete and brings you quite far
configuration is super; eg, creating your own color or default font is just putting them in your App.css and they override Tachyons; creating other breakpoints is possible (just change and recompile, this takes 1sec and a tachyons-cli is there, no need to touch webpack or eject CRA)
however, configuring Tachyons is not required at all, I tested it in and out and it's all perfect at the moment, it's really turn-key and absolutely the right approach to our problem; Tachyons does just one thing and it does is right
I preferred it very much over others like Tailwind because Tailwind has cumbersome and long CSS naming; Tailwind's philosophy and strategy is inconsistent; on the one hand, it wants to be atomic CSS, on the other hand, it bloats and pollutes your components almost like real CSS, wth? either I do minimal atomic CSS (it's called 'atomic'!) like Tachyons or I put real CSS in my component; Tailwind doesn't know what it wants to be while Tachyons has a clear strategy which is perfectly executed => an ultra atomic mapping to CSS, Tailwinds bobs up and down with some short names and then some long ones...; also setting Tailwind up or configuring is unnecessary complex and bloated; doc is comprehensive and complete but also because of its own complications and disunity; atomic css doesn't need to be science; compared to Tailwind, Tachyons is a dream
I also checked styled-system but found the DX not close to Tachyons and couldn't see any benefit over Tachyons; it's too cumbersome but in a different way than Tailwind
Tachyons is just 13kb gzipped while fully featured (Tailwind is 36kb)
while small Tachyons has the biggest ecosystem (related libs, cheatsheets, blog posts), at the end of the day, you don't need more, again it's just a mapper and more advanced stuff should be done with eg Emotion anyway[1]
[1] https://www.reddit.com/r/reactjs/comments/a6qhbr/checked_21_...
I wanted to try tailwind on a new CRA app but they’re using a version of postcss that just came out and has a bunch of compatibility problems.
> As of v2.0, Tailwind CSS depends on PostCSS 8. Because PostCSS 8 is only a few months old, many other tools in the ecosystem haven't updated yet
There’s a workaround but it seemed like something I’d have to workaround more than it was worth.
https://tailwindcss.com/docs/installation#post-css-7-compati...
Tailwind is not for me, simply because I don't want to have to learn yet another DSL that may or may not be abandoned in the future. I understand this is a personal decision though, but I've been burned too many times by fads.
My ideal CSS solution which doesn't seem to exist yet:
- Be able to write plain old CSS in JS/TS directly within a React component's tags, with a JS object literal
- Automatically generate atomic classes for each CSS rule (or block of rules) and have the system reuse those rules when the same styles are used elsewhere (no rule duplication means smaller bundle sizes for SSR, plus you get the semantic clarity of using plain CSS rules)
- Compiled, with zero or near-zero runtime overhead and critical path extraction, all cacheable by the browser. I don't want a huge runtime just so that I can dynamically apply a background colour.
The thing that comes closest to this is probably something like Linaria [1], but it relies on tagged template literals instead of object literals which means I can't use autocompletion. Their API for dynamic styling also relies on HTML data attributes, which is a little clunky.
Stiches [2] is another interesting project, however adoption doesn't seem very high and it seems to create superfluous wrapper nodes which can cause performance degradation in large VDOM trees. There's also no mechanism to colocate styles within a component's tags.
CSS Blocks [3] looks very promising also, but it doesn't allow co-location of styles with React components (you need to make a separate CSS file for each component).
[1] https://github.com/callstack/linaria
Genuine question, I'm a dev, but primarily backend and all my frontends are internal/chunky/it doesn't matter
I usually do 2 things when styling my crummy internal sites: a) manually write semantically-named classes for things that need it ("help-text", "external-link") and b) just in-line styles for everything else (esp. when a style really only applies to one element, or is intimately related to important layout considerations).
It seems to me that css classes which contain styling info in their name (h-32, font-semibold, text-cyan-600) aren't really any better than just in-line styles, and in fact maybe worse because they [seem to me] to just be an alias [which I have to learn, and will forget later] for a css style. Wouldn't it be simpler to just inline the style?
So my question is: what's the real benefit of this kind of css framework? What are the scenarios where it really helps to do styling this way? Is it just a performance thing? Is it about streamlining a dev workflow in some way that I don't get?
> The key to Tailwind's popularity is the painstakingly constructed system of design tokens at the core of the framework. The system's carefully selected constraints give developers just the right guardrails. They make it obvious whether a choice is good or bad by offering only discrete steps.
Can anyone comment more on this? As far as I see, there's still a big enough range of font sizes, padding/margin sizes, colours etc. that you still have to have an eye for design for the result to look pleasing. I've seen multiple landing pages made in Tailwind for example that don't look good.
Bootstrap in comparison will have a really uniform look if you use the built-in components, but you won't be able to build something that looks as good as Tailwind.
Semantic-UI [0] is also a well established framework for building up design using css classes and html only.
It's been more or less abandoned when the main developer got tired of it though, I really hope the same doesn't happen here.
[0] https://semantic-ui.com [1] https://fomantic-ui.com (Community fork)
Mhh... I don't know how to feel about this.
Over the last year, I've shipped a bunch of (p)react components [1, 2, 3] and what is cool about them is indeed that you can now encapsulate a UI function and make it re-usable within your project or even across projects.
In theory, this should finally give front end devs the same super powers as backend devs: high reusability.
However, a problem that I wasn't able to distinctly address is CSS. Currently, there's simply too many variants of encapsulating CSS into a "react module". You can opt to use:
- css modules
- styled components and derivatives
- CSS in JS or classes in JS, etc.
But ultimately, if you build your UI as a patchwork of many integrated UI elements (which IMO should be something legit in frontend development), you'll end up having to include 5 different CSS-in-bla libraries either in your build pipeline or (worse) in your bundle code that you ship to production (bloats the size and hence your app's performance).
Long story short: Combining styled components with twin macro and tailwind doesn't make my life easier currently. And the benefits to my users will not be apparent directly either.
Not to say that all the CSS-to-XY movement isn't cool. Still, I think the best solution to this problem has yet to be discovered.
1: https://github.com/TimDaub/preact-touchable-dock
Can anyone recommend any text-heavy tailwind themes? Or - are themes even viable with Tailwind?
I'm a backend Dev who plans to buy Tailwind Build (or w/e it's called). I enjoy the idea of not having to worry (as much) about design, and instead just focus on content layout, etc. Tailwind is neat that way.
With that said though i'm not a fan of the .. "modern" design. I'll use it, i guess, but on text heavy pages ala Wikipedia or HackerNews, Tailwind looks like it would waste a lot of space. Though maybe i'm off base.
The point of this is to ask if theming has gotchas. Eg maybe themes work, but they're rarely ever supported well enough, leaving you with little gaps in design that cause problems. Thoughts?
I'm personally a big fan of Tailwind + either HTMX or Alpine.js, as it lets me easily generate modular UI components in the back-end using the 'dominate' Python library, without having to fuss around too much. (Other frameworks such as React should work as well, I just haven't experimented with them very much so far).
Munging these tools together has let me create my own 'distributed back end framework', so I can define back-end logic and front-end logic in the same place, but have the back-end logic run on whichever machine I choose, so e.g. an edge device can send a fragment of UI to a monitoring dashboard.
It's all rather nice and I'm very pleased with myself. :-)
Was always curious, why it was Tailwind that won 'utility-first css' and not https://tachyons.io which did this approach first.
Atomic CSS is not ideal for performance. No tooling can extract the per-page critical CSS, so you end up shipping more CSS to the browser than necessary. The bigger and more dynamic the app, the more unnecessary code you will ship.
Do people actually generate a CSS file for every page?
I think the original concept of using inline styles in your React components was truly a leap forward in terms of styling DX. It seems like most of the developments since (CSS in JS, Tailwind) have just been more inefficient ways of implementing that core inline styles concept. Ok, these new solutions give you pseudo classes, but those can easily be replicated in JS. Beyond that, I don't see the upside of the additional complexity these solutions bring vs plain inline styles.
not related to the article at all, but figure I'd share this thing that was recently released (no affiliation, just a fan of marcel's work) : https://usewindy.com/
Any alternative to Tailwind UI? I can't justify that price for hobby projects. I'm also not interested in material-ui which is becoming open-core.
I really like Tailwind but has anyone figured out how to get it to run quickly in development with Webpack?
For example Tailwind 2.0 out of the box produces around 3.5mb of CSS and Webpack 5+ on an SSD takes 5+ seconds to start things up. This is a problem with Docker because if your main app container needs to be restart it involves stopping Docker Compose and then upping things. This means your app is delayed 5+ seconds from starting. In production it's no problem with purge CSS and your build step producing the final assets out of band, but I think having a top notch dev experience is really important.
You can do some hacks around how Tailwind imports its fils to make CSS updates happen nearly instantly but the initial Webpack start up time still suffers.
Currently I get around this by enabling Webpack's filesystem cache but this seems like a band-aid solution.
Any suggestions?
On a non-SSD machine I noticed the start up time being 28 seconds btw. It's a non-issue for me but if you want to make open source projects that others use, a ~30 second start up penalty in development is a killer for a pretty large chunk of people.
The one criticism it's valid to level at Tailwind is it doesn't play nicely with the CSS cascade.
Take their plugin, https://tailwindcss.com/docs/typography-plugin. It lets you define text styles for regions (handy when you render Markdown into a div, for example).
Imagine that you have HTML inside that div, with TailwindCSS classes applied. The specificity of the text styles for the region override the classes, which isn't what any end-user wants.
The guys behind Tailwind acknowledge this, but there isn't a good solution for it. It's not a TailwindCSS-only problem; I've written plenty of CSS by hand which has this issue.
But when choosing a framework based around element-level classes, this is a limitation which is important to keep in mind.
In https://news.ycombinator.com/item?id=25305467 there was talk about the PETAL stack of which Tailwind is a part. It consists of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView.
It is entirely possible to have a "semantic web" and tailwind at the same time.
IMHO the perfect combination is BEM naming that is purely semantic combined with tailwind cruft that is purely visual.
So you can end up with:
<div class="profile_card a-bunch of-tailwinds classes">
<div class="profile_card__heading more-tailwinds-classes">
<h3 class="even-more-tailwinds-classes>Hello World</h3>
</div>
</div>
I also love tailwind! To me it feels like the defaults are sane enough + an amazing documentation which summarizes all the CSS I use.
Most of the time I think:
"I need a small margin on the right and a big one at the bottom, and let's see a black background" which is super cheap to mentally translate to "mr-1 mb-10 bg-black" while staying in the HTML. If I'm repeating too much I can either move that to a custom tailwind CSS component or a react component. It just feels easy working with, and it's super flexible.
I still think that this kind of approach it's only a "problem moved" from CSS to inline HTML, which makes me mad because i still need to jump from HTML to CSS all the time, plus custom modifications can be painful with tons of overrides and "!important"s. Exactly like bootstrap.
BEM (with none-to-few utility classes) was a game changer to me (even if far from perfect) and its most natural conseguence are web components.
I'm loving the Bulma approach BTW.
Tachyons needs this for a button:
<a class="f6 link dim ph3 pv2 mb2 dib white bg-black" />
You can see the button rendered here (the first at the top): https://tachyons.io/components/buttons/basic/index.html#0
I've not yet tried Tailwind, but I've found the utility classes in Bootstrap to be really useful. Over the years I've encountered a good number of instances on larger sites using traditional/global CSS where a change to a particular style ends up unintentionally affecting random stuff elsewhere. It's really irritating.
A design question if I may. Site states "gives developers without a deep understanding of design the ability to build visually gorgeous, modern user interfaces".
I really don't understand this statement. If you are bad/good at design, how does Tailwind change anything? Can anyone please describe what it is/feels like in comparison?
My opinion moved from liking tailwind to loving it when tailwindplay got realsed (play.tailwind.com). It's so cool, and faster than any hot-reload ever will be. It's in my opinion is the smoothest way to create UI components on the fly with ease that of drag and drop tools, but with much more extended functionality.
I've "learned" CSS through Tailwind, was using it for a couple of years and I'm now able to build my own design systems in CSS. The reason I moved on is that I wanted a slightly more opinionated system and a different naming scheme, especially for colors.