I’ve been using tailwindcss and tailwindui for our production platform (released), and our new website (in development) and couldn’t be happier. Once you get the hang of it, you’ll be able to build stuff very quickly. For our production platform, I have it running on top of Angular and Angular material. Getting tailwind, angular, and material to work together wasn’t easy, but once I got it up and running, it was pretty straightforward to start building new pages or modify existing ones without having to change existing styles.
I had two major complaints and this update fixes both. The first is the enormous size of the css file locally, which caused the browser to become considerably slower and made the developer tools really slow to load when selecting elements. The second was the lack of the !important selector.
Oh is THAT why my dev tools are so slow? Especially in Firefox, selecting elements has been really laggy. I figured it was because of my crappy laptop.
I also love Tailwind, glad to know it's about to get better.
I still don’t get the tailwind hype. To me, I think the relevant parties are invested, myself included. CSS is weird and has had a lot of “answers” appended to it out of desperation, but I’ve been feeling really good about styled-components and/or SASS modules, probably slightly in favor of the former, using file based code splitting. I’ve seen the explanations countless times, but if you were to ask me to advocate for tailwind right now, I’d find it difficult to highlight the advantages. The answers don’t immediately jump out at me, the problem we’re solving doesn’t seem immediately apparent, so I have trouble advocating for or understanding the tech.
“You can build stuff quickly!” - doesn’t this just sound like someone comfortable with raw CSS?
“You don’t need to context-switch!” - these are shorthand classes, not JS or JSX. The language isn’t uniform here.
Note: I’ve written a lot of CSS and generally prefer rolling my own components to using a library... perhaps I’m not the target audience. Perhaps this is a cherry flavor to make the “designing your own UI” medicine go down more easily. Perhaps I’m mistaken and not being charitable enough, too.
I think frameworks like tailwind are great for rolling your own components actually. Tailwind sits somewhere between just writing your own styles from scratch and using a css component library like Bootstrap. It provides you with sensible atomics (e.g. a nicely defined range of margins/paddings that allow you to create UIs with consistent spacing), but it still allows you to mix and match where needed.
This approach allows tailwind to be terser than raw inline styles, while giving you the ability to write a lot of your styling inside the markup, which prevents context-switching. It's a nice balance between many of the approaches that have come before it.
Think of tailwindcss an html-level "API" to a Design System - it provides a consistent color scheme, consistent padding/spacing, it uses a familiar naming scheme that aligns closely with the the original CSS naming. It's also easy enough to extend with your own customizations as well, particularly once you get a grasp on the advantages of atomic CSS [0].
I think the fantastic thing about is the natural feeling constraints that it gives you, and not having to think about naming stuff or building out a CSS project (with standards etc) that scales at-all well (which is often a suprising amount of fuckery).
If you're using styled components and you want a small margin you have to do something along the lines of.
Presuming you've set up a file full of font sizes, margins, paddings.
In TailwindCC you get a bunch of very sane, well picked defaults chosen for you for free, by default. You write in a simple DSL and don't have to worry. You can update the defaults as you see fit, too.
<div className="m-1" />
This has autocomplete, etc etc.
IF you don't want the clutter of all these utilities, you can abstract them away into smaller components as you already should be doing. You build your component library with speed and can focus on the actually interesting parts of your system as opposed to wasting time naming stuff or pissing about with CSS.
And of course, if your div is reused a lot, you naturally abstract it into a component at a time that suits you!
I'd say try just using for a project or two and you suddently realise you were wasting a whole lot of time and effort before.
Anything truly dynamic calculated can go also into a style= prop. They work great together!
I was so sick of working web because it felt like working in CSS was a total footgun unless you spend a lot of time making a solution that does things right. Now I find working on web projects a joy again.
If I want this dense notation I can name the custom property `--m-1`. In most IDEs (or language servers) I’ve tried custom properties also have autocomplete.
That is I use CSS custom properties inside component scoped styles. (Component scoped styles is what I call the general idea that React’s styled components are implementing, but Vue’s SFC and the shadow DOM scope the styles to the component at hand equally well).
I’m not saying “Don’t use Tailwind; use custom properties instead”. But for those of us that don’t like the idea that Tailwind brings, there are options, and we are perfectly happy with what we got.
Many people had to try it to really understand what the hype is all about, so it's pretty clearly difficult to explain.
If you give the combination of Tailwind + Alpine.js + your favorite server-side templating engine a try, it may just click. At least for me, that was the key.
To me, it seems like a really bad sign if something that is supposed to solve a problem is “hard to explain”, almost like it doesn’t actually solve any problem and just ropes you in with familiarity.
My assessment is based on the fact that when you design something, you generally have to be able to explain its value, with little exception.
What I don’t get is that everyone is always acting like Tailwind invented this approach to CSS. It’s been a thing for at least 6 years or more, far before tailwind. Granted I suppose they have really brought it to the mainstream.
As someone who’s used this approach in production for years I can vouch for it. It greatly reduces complexity and is easier to maintain. Day to day no one is writing any css at all, nor are they bogged down with naming conventions, etc. You just “snap” together your utility classes ad-hoc as needed.
Responsive breakpoints are also much easier to work with because they’re just “built in” as modifiers on all the base utility classes.
Tailwind is quite convenient for standard web projects. The advantages are less apparent in React projects, especially if you use styled-components or robusts frameworks like ChakraUI.
I tried JIT mode, loved its features like arbitrary styles, but eventually I switched back to default tailwind config.
So, when you use JIT you no longer get all tailwind classes in chrome dev tools only the ones you applied to components. I know it's by design to keep css lightweight. But that also means I can no longer design UI using Chrome dev tools. Only when I apply tw classes directly to component in editor like vscode it reflects the change in browser. this back and forth cycle between editor and chrome took the fun away from me :(
Somebody already wrote a library for client-side JIT TailwindCSS. and tbh I really want this taken to the extreme and see how much is the overhead compared to shipping + parsing CSS. https://github.com/matyunya/headlong
I've posted before, but will throw this out again.
When I'm building, I'm typically using a toolkit like vuetify or bootstrapvue. These are dozens of components - tested, documented, expanded on, and styled (using bootstrap or material design or... whatever).
The 'just to go tailwind!' I keep seeing seems to assume I want to rebuild components (and then test them) which already exist, and are designed to work together. The common refrain is "but all those sites look the same!" but... I can change colors, sizes, and... when needed, a bit more, by going in to the scss (or similar) and recompiling.
I understand the 'purge' stuff in tailwind is nice and useful (tested it firsthand) but the time/effort of rebuilding large sets of components (which are, often, by and large commodity things) is so far a hard sell for me. I was on a team last year that was in their second round of developing their own in-house UI toolkit - basically recreating most of bootstrap-react, but poorly, and with no testing or accessibility, because "bootstrap is bad". They were so far behind they thought they were ahead...
I'm just not grokking all the tailwind love. I've played with it, and yes... I guess anything that you learn and spend time with will, overtime, become 'natural' and save you time.
It's impressive tech, for sure - not trying to downplay it.
It sounds to me like you are just not the target for something like tailwind. My impression is that you are likely building displays that only require a few different UI components (and probably the ones we all see regurgitated over and over). The kind of UI where the star of the show is the information you are displaying rather than its behavior (of course there is a balance).
But for the kinds of applications I build there simply does not exist a “UI toolkit” that could save me any amount of time worth the hassle of ingesting another library and finagling it to my needs for what? Maybe 15% of my UI? The value in the tools that I build is partly in the UI I make to interact with them.
There is nothing more frustrating than the 5th or 6th time you just need the padding to be a little different to make your component pop, and you have to slog through the docs/source figure out how to adjust 2px...
What kinds of applications do you build? It sounds like having pixel perfect components that match exactly what the designers want is a really high priority for you. And that is fine but man it can really make dev go slower than using existing ones and I'm not always sure it's worth it.
I work in the fantasy sports domain with my primary focus building league management/draft software. I am both the "designer" and the developer of the tools I make. And I honestly wouldn't describe myself as someone who is overly pedantic about "design" in general.
But you may be surprised how often (and consequential) something as small as 2px padding, or line heights, or borders, or... [the list is just endless] can affect the final product. Especially once space starts becoming an issue (or you care at all about alignment).
The components of such software as the above are not "cards" and "lists" and "buttons", rather, it's "rosters" and "depth charts" and complex tables full of stats that need to be sliced and diced in all sorts of ways. A generic library (especially the kind that loves putting large swaths of spacing between things) is just not tenable.
Tailwind completely absolves the issues of managing literally hundreds of bespoke components on screen at once -- none of which can/should be reused in any sane sense of the word. Classic CSS quickly becomes a huge pain for the above. It's just... simpler to slap all of the styles inline right into the element. It took me no more than 2 days to become rather adept at using (and extending!) tailwind. At this point I simply cannot imagine doing it any other way.
In that case wouldn't an existing component library be better? For something like that it seems function would be favored over design so you could get away with a generic looking component library.
My thoughts exactly. Especially if "do it exactly as non-dev design folks who don't actually ever write functional code decided it should be 3 months ago before they moved on to another project" isn't a requirement, something like vuetify gives a lot of functional and visual consistency (while providing standard support for a lot of accessibility stuff), in a tested and progressing toolkit.
A colleague consolidated new dev at his employer under vuetify and it took away some of the "design meetings", and allowed them to turn around projects faster (anecdotal, to be sure). All internal 'line of business' type stuff.
I mention vuetify as its faster to type than 'bootstrap-vue', but BSV is what I've used more. Used vuetify on one small prototype at the suggestion of some colleagues - some differences and nice aspects compared to BSV, but I default back to BSV for familiarity/speed/completeness. vuetify seemed to have some nicer defaults for accessibility compared to BSV, but it wasn't enough to make me switch (also, because... I'm not a huge MD fan either).
Often the developers have very little choice. They're handed a spec and told "go make this" and what they make has to be pixel perfect. Personally I think that very very few businesses actually need to do this, and adopting this way of thinking is backward and counter-productive (especially when perhaps more important things like accessibility are not even a consideration), what I think isn't the point.
You're right though that a lot of people who jump straight to tailwind probably don't realize that its low level might be too low for their needs. A higher level component library like bootstrap, tailwind ui, chakra, etc. is a better start in many cases.
I actually bought this quite a while back. It is nice, but a far cry from what developers typically consider components. In fact they are just HTML that you have to copy and paste. You have to build the interactivity yourself. I think they have recently started integrating them into some JS frameworks though possibly.
Ah, yeah component makers are in a hard spot right now. You can't really write a 'generic' component easily and have to take a bet on using whatever JS framework is in vogue--react, vue, etc. It's not easy for a react project to pick up a vue component and use it or vice-versa. Even ignoring the framework incompatibilities, it also requires your component users to now buy in to the whole bundler game.
You could work around this by sticking with a generic, simpler framework like good ole jQuery. But now your framework users in react, vue, etc. are mad that they need to pull in kilobytes of JS that's doing what their framework already does.
So... as a component author a bundle of HTML and bring your own logic is kind of the only low-level option that's ubiquitous. Things might get better with web components, but it's not all there yet.
Thank you. That's all it seems to be to me, and when people say "look at these components", it seems like they've not seen value in vuetify, for example.
I made a comment above, which got downvoted, but, I'll try to explain a bit more. Looking at tailblocks site ... it's just html/css (verbose tailwind). Having lots of markup for input boxes that don't have any affordance for validation states, aria tags - that's a lot of code in those example blocks that still forces me to have to add lots more stuff to get some basic interaction functionality that's already provided by other toolkits (which, again, all use a common base and therefor all are styled similarly without the need for a lot of boilerplate css).
Someone posted above that tailwindui(?) will be providing react and vue components - that may be worth investigating later. Possibly too late for some current projects, but I'll keep an eye out.
But replace "launch vehicle" with "in-house UI toolkit".
It baffles me that people time and time again make the judgement that their several months of work are somehow more worth(in terms of effect) than literal man-years put into a decent UI library.
Yeah I'm in a similar position. None of the TailwindUI components have the logic built in, it's just the markup so you need to build the components yourself. I like the feel of Adobe Spectrum but it doesn't have exactly all the components that I want so I'd have to make my own components, and the styling looks somewhat complex to modify such that it doesn't look just exactly like theirs.
I'm looking into their react-aria and react-stately libraries which appear to just give you the hooks that power the UI components and then you can supply your own markup.
Tailwind has headless-ui coming out soon which appears to be very similar to the aforementioned two libraries so that may fill the void but it'd be nice to have a something now. At the moment I'm using Tailwind for mainly static informational sites rather than interactive UIs until I get around to making an internal library of components that I can style with tailwind css. At the end of the day it's basically just CSS anyway.
The big advantage of tailwind for me is that it solves responsive design better than any system I've used before. I'm not amazing at frontend styling (I get by), but I feel like a superhero with tailwind css and UI (worth the money)
That's interesting, I love Tailwind but I think Tailwind's responsive stuff is the messiest part. Do you have any good resources to share about doing effective and maintainable responsive design on a non-toy website using Tailwind?
Not really any advice here. I am using it for my product and it has been basically changing up the design as needed. It's pretty common for me to make use of grid-cols-1 and then something like md:grid-cols-2 or 3 to keep it single column on mobile and multi-column on desktop
Ok that's what I'm doing too! It always works but also feels a bit messy and when I want to make a change it ends up being hard to untangle all the nested selectors.
I may just be being pedantic here, but isn't this AOT rather than JIT? JIT means the optimizer is code that ships as part of the runtime, which is sort of the opposite of what this does.
I've started investigating whether a truly "just in time" variant of Tailwind is reasonable. It's almost like a CSS transpiler - converting tailwind classnames to their CSS form.
You'll probably always want AOT for the "critical css" in the first load, but afterward, JIT might be reasonable.
At a minimum, it should be feasible. You can override Prototype's appendChild, replaceChild, and insertBefore to grab classnames and generate CSS before the DOM is updated. Everyone will tell you this is insane, but it seems to work.
But it's unclear if this leads to something "better" than the AOT solution. It feels like code golf: will the transpiler have less bytes than the CSS generated by a pure AOT solution? The tailwind folks have come up with a really dense way of expressing verbose CSS, so I think it's possible!
No affiliation to Tailwind. Just playing on weekends.
Thing is, what they had before is also defined as AOT (of the build step) too. JIT here refers to the Just-In-Time for the build, not for the client. Saying it JIT is clearer in the context if Tailwind, but not in general.
This is one of the reasons FE JS ecosystem is confusing as this also happens with the code (ex: process.env for environment variables only exists in the build step, not in the browser, but the code is mingled in the same file).
Deviation between build-time and run-time is...normal. The fact that JS is a dynamic language that doesn't necessarily require a build step, but we've introduced one anyways, doesn't really change the equation.
It's still exactly the same problem as building a C codebase versus running it.
The reason the FE JS ecosystem is confusing is because there's this absurd pretense that they're doing something novel whenever they implement a feature or tooling that has existed for decades (just not for JS). And then, because its novel, they come up with new names (or misuse old names, like here) because they either intentionally or unintentionally avoid using the 1:1 mapping with standard tooling.
Just-In-Time for the build just doesn't make sense -- a JIT is a very specific thing; it compiles code at runtime. The term exists specifically to differentiate from compilation at build-time. If you make a JIT for build-time, you've lost all meaning
This is just rebuilding the code more often... through a filewatcher.
Also worth mentioning that rebuilding on file system events is something that already existed in the JS space, and it's typically just called "watching". Even the compile-only-what-is-needed part already has established terminology (dead code elimination in the general case, and "tree-shaking" in the JS NIH case)
Tailwind clearly is trying to put some effort into marketing, but IMHO misusing established terms like this can backfire in the sense that it makes them look like they're out of their depth wrt compilation literature.
Large companies have too much baggage - fear of breaking compatibility, and don't develop new enough things.
There is a certain size where changes are exciting, or certain company cultures that encourage new stuff. Tailwind is there, and it is always fun to get their update emails.
I used tailwind for v1 of my marketing site and it seemed fine at the time. Fast forward to when I needed to make some changes and some tags had 10+ modifiers on them including custom ones...it become so hard to figure out what was doing what without massively breaking things. I've since moved back to component libraries for their simplicity.
Love Tailwind. It delivered on the promise of what I always wanted Bootstrap to be. Most notably, the `@apply` directive making it possible for me to refactor out my tailwind utility classes that I prototype with means that I can move fast and not end up with an eventual mess.
I'll echo other folks who have said that using Tailwind has significantly increased how quickly I can put together frontend stuff -- it's close to a 5x speedup for me workflow wise.
Ehhh, systems outside frontend are just as complex. Think of a backend service--you've probably got a low-level TCP/HTTP handler written in a fast systems language like C/C++, then your business logic written in a higher level language like Go/JS/Ruby/etc., and that's interacting with your data layer using a completely different logic-based SQL language (and extra complexity to translate that SQL to your high-level language with an ORM layer), and on top of that you probably have a rules engine for authorization because you realized the systems language was too slow to update and deal with fast-changing business requirements.
This is really not that different from the frontend world where you've got a markup language to define semantics of the view, a logic layer in JS to pull in data with web requests to populate the view, and CSS as a style layer to make the view look good.
I downloaded the tailwind-jit repository, and after a good coffee break and "npm install", it's 120 megs. But I'm not that worried, give it a few cycles and we get esbuild for tailwind, which should bring it down to a simple barebones 8 mb Go binary.
I was once a massive Tailwind hater. I remember walking around Ipswich with a close friend who is also a developer proverbially slagging it off and all those that espoused it as the next best thing since sliced bread. Then I actually thought “well I’d better jump on this bandwagon before I’m unemployable”. I’ve never been able to build stuff so fast. I’m absolutely floored by the small learning curve and the speed at which I can put things together, especially with the help of TailwindUI too. There’s something huge to be said about the fact that I don’t need to context switch to CSS-land out of my markup to style up what I’m doing. I didn’t realise it, but that overhead of switching to a style sheet and going back to modify markup and then viewing the results in the browser really just used up my mental energy battery. Now, if I was in prison with Adam Wathan and Steve S, I’d 100% protect them in the showers if they dropped the soap.
> There’s something huge to be said about the fact that I don’t need to context switch to CSS-land out of my markup to style up what I’m doing. I didn’t realise it, but that overhead of switching to a style sheet and going back to modify markup and then viewing the results in the browser really just used up my mental energy battery.
Welcome to what us React folk have been saying since at least 2016. Splitting your code by language is bad. Vertical slices for the win.
Agree. Vue and Svelte get this right as well (assuming you use SFCs properly), except they don't have bizarre preferences for one-way data binding everywhere or typing className instead of class.
Agree with this. Although I’m gonna say it is not the single file per-se which is the winning technology here but the component scoped styles. When writing vanilla web components this can be accomplished with `this.attachShadow()`, and in Stencil you write an external stylesheet and reference it with a `styleUrl` in your `@Component` decorator.
In fact it is kind of nice to put your styles in another file if you have a designer on your team who is afraid to touch any files that don’t have the `.css` extension.
I love how quickly you went from publicly denouncing Tailwind to panicking that you would be left behind and jumping on the bandwagon. I'm imagining this psychological drama playing out within the gap between two spoken sentences to your friend and it's hilarious.
I completely agree with your points on mental energy expenditure and speed of development. I thought it was a bad idea, but I’m now 3 months deep into a big project using it and I will never go back.
It's also very nice when you're moving some markup from one file to another and not having to worry about where certain styles are coming from and copying those over too
> Now, if I was in prison with Adam Wathan and Steve S, I’d 100% protect them in the showers if they dropped the soap.
Sorry to go on a tangent here with a commentary unrelated to the discussion at hand (which is indeed an interesting one), but can we please stop with the rape jokes. They are not funny, and may be triggering to a large portion of your readers.
I'm glad someone said this before I did. Male sexual harassment has been so normalized in media over the years that we can barely recognize it in the wild. As a man who has dealt with sexual harassment before, I feel like we should talk about it more.
I just ducked all that, and started writing a plain old CSS with BEM like a mad man, and know what with a bit of discipline and good methodology it works as magic.
Yeah I'm with you in that plain old CSS is still perfectly good. Now with CSS modules and constructable stylesheets it's getting better to make isolated components too.
I think a lot of the love for tailwind are people finally getting the mental OK to remove the strict isolation of style and template/code which has been dogma for 20+ years. If you're using something like vue, svelte, or a good web components library you can just define components with all their markup and style in one place, all using bog standard CSS. It's fine.
Don't want to take away from Tailwind, it's great.
That said, self-promotion disclaimer but if you like inline/utility CSS, and also like TypeScript/React/Emotion, we've got a "Tailwinds-ish" CSS-in-JS library that we've enjoyed so far:
I love TailwindCSS, and this just made it better than I wished for. It was always annoying having to use style attributes for specific, one-off things and it's great knowing that it won't be a problem anymore. Not to mention of course the performance improvements.
Can't wait to upgrade Tailwind on my project and try this out :)
I am really a huge fan of esbuild. I know evanw is working on implementing css module support that has the same tree shaking ability as the js bits. This means the bundler only ships the css that is actually used.
I feel tailwind is somewhat going down that path, but I wonder if this is a problem that a bundler can solve.
I use tailwind with tsx react components and it seems the tailwind just-in-time mode won't work with that.
This is something of an aside, but the design of Tailwind CSS classes inadvertently (or perhaps not) makes developing custom user styles nearly impossible.
When Laravel refreshed its documentation design, I wrote a stylesheet to revert it almost entirely to the old design. I could do it because restyling something like `.sidebar` is super simple. The new class list is
Kudos to the team on the release. I'm a huge fan of allowing CSS via arbitrary class names. I work on team that is in the midst of migrating a large codebase away from custom global CSS (with BEM) to Tailwind. We frequently have to augment our tailwind.config.js file by adding one-off settings and that has always felt wrong. This should solve that pain point.
One area I'd love to see Tailwind tackle is better targeting for child elements. I understand the library is functional and the classes are atomic, but I think being able to chain and target arbitrary children elements would be quite powerful.
Inline styles apply all of the time. With a class, you have access to media queries and thus some basic form of logic.
The “md:” prefix is used exactly for this. It applies any following class at a medium media query breakpoint. Same thing with focus or hover styles, also impossible with an inline style attribute.
The custom overrides are obviously more one off and less reusable, so the difference between those and a style attribute are less obvious at first glance. With classes though, you are bound to the class names in your stylesheet and thus some form of sanitization/linting. Inline styles won’t stop you from breaking your design system.
I wish there was a convention on the order of classes on an element. Like height/width first, padding/margin next, idk what next, and then pseudoclass variants at the end, but in the same order?
I don't know honestly, I just wish there was a convention.
The problem is more, that to my knowledge, none of them got wide adaption. You could at adapt them on at least a company/team wide level, but don’t know what tooling there is to make it easily configurable.
I like this a lot actually, considering JIT maybe data attributes or some tighter integration into react could easily be done so there isn’t so much reliance on class names.
The convention I have started using is “outside in” meaning first the margin, then the border, then the padding, etc. It’s not perfect because a lot of stuff is “in” (font family, text color, etc.) but it at least gives a rough directionality to things.
I’m ok with a convention but considering how that could become it’s own complete config maybe alphabetical would just be better. Also it typically has less issues with git changes.
There's Headwind CSS, which orders classes predictably. But it doesn't move them to separate lines. This could be a config option if you're willing to write a pull request.
Utility css frameworks seem to boost productivity but was that ever a problem? IMO the big problem with CSS is maintainability. I was all hype about Tailwind CSS until I had to go back to a project and make adjustments. This soup of CSS classes is no better than a long regexp.
If anyone is looking for practical examples of using Tailwind + the JIT compiler with various web frameworks and Webpack, I have a few example starter projects at:
Yup! I think the biggest win for me is not having to worry about CSS class names. Some people hate the fact that the HTML is now less "clean" but I appreciate not having to context switch or deduce that a child a tag inside a a div.card has a specific styling.
I had two major complaints and this update fixes both. The first is the enormous size of the css file locally, which caused the browser to become considerably slower and made the developer tools really slow to load when selecting elements. The second was the lack of the !important selector.
This is a solid update. Kudos to the team.