---
title: Tailwind CSS with Adam Wathan
date: 2022-02-22T05:00:00-05:00
author: Sean Smith
canonical_url: "https://website101podcast.com/episodes/season-05/episode-4/tailwind-css-with-adam-wathan/"
section: Podcast
---
<!\[CDATA\[YII-BLOCK-BODY-BEGIN\]\]>[Skip to main content](#main-content)Guest Adam Wathan
CEO at Tailwind Labs and creator of Tailwind CSS, author of Refactoring UI, Refactoring to Collections, and Test-Driven Laravel, and host of the Full Stack Radio podcast.
[ ](https://twitter.com/adamwathan)
Season 05 Episode 4 – Feb 22, 2022
1:02:10 [Show Notes](#show-notes)
## Tailwind CSS with Adam Wathan
0:00
0:00
1.0x
0.75x1.0x1.25x1.5x2x
[](//dts.podtrac.com/redirect.mp3/website101podcast.com/uploads/mp3/season-05/S05-E04%20-%20Tailwind%20with%20Adam%20Wathan.mp3)
Adam Wathan, co-founder of Tailwind CSS, talks about what Tailwind CSS is, why he built it, and the future of Tailwind.
### Show Notes
- Is Tailwind CSS a framework?
- What is Tailwind CSS
- The biggest inspiration for tailwind is...
- Inline styles vs Tailwind
- Tailwind 3 and Just in Time (JIT)
- Build tooling
- Tailwind Browser Dev tools
- Arbitrary classes
- Tailwind UI
- Tailwind documentation and examples
- How to choose what to add in Tailwind.
- What makes something a plugin rather than part of Tailwind core.
- Tailwind 4 and the future
### Show Links
- [Tailwind CSS](https://tailwindcss.com/)
- [Bootstrap](https://getbootstrap.com/)
- [Atomic CSS](https://acss.io/)
- [Tachyons](https://tachyons.io/)
- [BEM](http://getbem.com/)
- [Tailwind UI](https://tailwindui.com/)
- [Refactoring UI](https://www.refactoringui.com/)
- [Tweet about running a product](https://twitter.com/adamwathan/status/1472031524639977479?t=l--rW9eHHn9zWtMYB3cN-w&s=19)
Powered Transcript Accuracy of transcript is dependant on AI technology.
**\[00:00\]** **Sean:** Welcome back to the website 101 Podcasts Season 5 episode 4. This is the podcast for novice web developers and small business owners who want to learn more about running and optimizing their websites. Sean Smith is with me. Sean, how you doing today? I'm doing great. We're recording
**\[00:21\]** **Mike:** just before Christmas and we're looking forward to our guests this week. Yeah, this is another one
**\[00:28\]** **Sean:** that I'm really excited about. We have a guest Adam Wathen on the show. He is a podcaster. He's a host of FullStackRadio. He's also, you know, big in the Laravel community, I believe, and he's of course best known for being the guy behind the guy when it comes to tailwind. Everyone's favorite CSS framework. I would call it a framework. We'll find out if it's a framework. Anyway,
**\[00:52\]** **Mike:** Adam, welcome to the show. Hey, thanks so much for having me. Really exciting to have Adam here. I've been using Tailwind since it was in version 0.5, I think, and I convinced Mike and some other people in our local group of developers to try it out. Not everybody's on board, but Mike is definitely on board with it. And yeah, Big Tailwind lover here. Awesome. So let's just get into this.
**\[01:22\]** **Sean:** Adam, I said earlier that I would call Tailwind a CSS framework, something that helps you write CSS better or not. Well, why don't we just hear from you? How would you describe Tailwind to some, like, I guess, elevator pitch? Can I just bump in for one second? Yeah.
**\[01:40\]** **Mike:** In the last episode where I interviewed Mike, I said that Tailwind is not a framework. So we're going to find out.
**\[01:49\]** **Sean:** Yeah, there's a bit of a disadvantage. He thinks it's not, I kind of think it is. What do you think?
**\[01:54\]** **Adam:** Yeah, I guess I don't really pick on the terminology too much. I think of it as a framework in the sense that it's a kind of convention-driven system for helping you build things faster without having to make as many decisions. But it also is kind of a tool for generating your own CSS framework on a project by project basis, too, because of kind of all the built-in customization and extensibility stuff, which was a really sort of core and important thing from the beginning, because the whole point of Till when it was being developed was to figure out a way to create something. Basically like I always felt like when I was building websites, I had two choices.
It was either use a framework like Bootstrap or Foundation or something that was fairly opinionated and higher level that would let me move really fast but might give me a little a bit of grief if I wanted to really do something that looked different than the opinions that were sort of baked into the tool, or I had to just crack open an empty CSS file and get started from scratch. And it felt disappointing to me that those were the only two options, and that there was no middle ground. There was no way to come use some tool that made it easier to build something totally custom you know, instead of just using a vanilla CSS. So that was the goal with with Tailwind was to build a CSS framework that helps you build custom designs and custom websites without having to do everything from scratch every single time.
Yeah, so that's that's kind of the the origin of an in that sense. And why I guess, you know, I do think of it as a framework. We call it a framework on the website and stuff like that. But it is a different at a different level of abstraction then a lot of other tools of columns.
That's frameworks
**\[04:06\]** **Mike:** Yeah, all right. So I guess I'll call it a framework now But you know potato potato
**\[04:13\]** **Sean:** Let's just actually take a bit of a step back here and describe for people who don't use tailwind kind of What it is and what it does and how it's different from foundation So I would I would describe it as Well, in terms of how it gets used, instead of assigning an element a class name, going into CSS and writing a whole rule around that where it has underline text and bold font or whatever, you actually add those classes that represent each of those properties right
**\[04:44\]** **Mike:** on the HTML so you would add underline font-bold and so on.
**\[04:50\]** **Sean:** And it sort of writes its own CSS as you do that. So as you said, it makes, for me, and Sean, I'm sure you would agree, makes development just way, way faster because you're not going in and making your own rules for every little element. And oh, I need a different heading in this one case. I got to write a whole new rule for this one heading and things like that.
**\[05:10\]** **Mike:** It saves a lot of cognitive energy of creating class names and it increases my speed of development significantly. At first, I was put off by the class name vomit pool that you get, and that's a common complaint that you hear. But I decided, okay, I heard a little bit of buzz about it. I got a personal project which we're now recording an episode for.
So this was my, the podcast website was the first thing I did tailwind with. And I was like, okay, I'm going to give this a shot. Within 30 minutes, I was sold. Yeah, awesome.
It was just amazing. I didn't have to switch files. I didn't have to think of clever class names that weren't used elsewhere. I didn't have to consider the cascade.
Everything just worked. And this is in 0.5. Yeah. Tailwinds really come a long way since then.
**\[06:06\]** **Sean:** Yeah, the thing I really like about it is it sort of takes advantage of the modern web in the the sense that you're going to be using four loops and things like that when you're developing your HTML. I can see someone saying, well, if I have to add all these classes to each element, if I have a news page, and it has 10 elements on there, you want me to duplicate it throughout, well, you're not doing that. You're probably using a CMS or something where it's iterating through one implementation of that, and it's just looping it. So you only put it in once, so that's, you know, CSS, traditional CSS I find has stagnated when it comes to where the web has gone, like it's not as efficient as it was way back in the day when we didn't have these tools, right?
So that's one of the things I really like about Tailwind.
**\[06:56\]** **Adam:** Yeah, I think definitely, the reason it works is because we have better tools for creating abstractions than just CSS. And you have to sort of think about the tools that you're using holistically, I think, to realize that it's easy to say when you're just looking at the CSS side of things, well, this is going to result in lots of duplication. This is going to be really painful to maintain. But the reality is so often, you're only writing the markup once.
You know, if you were looking at say, um, say you're building a cassette with Bootswrap and I only make these comparisons because Bootswrap's kind of built a different way. Bootswrap is actually the biggest inspiration for Tailwind. And I, a huge fan of that project. And the people behind it.
And I learned so much about how to build Tailwind and how to write CSS and stuff from those guys. So always be appreciative. Um, but it's interesting to make the comparison because it operates at a different level. But if you look at something like a nav bar that you might get with Bootstrap, you have a class like nav bar with a couple sub classes and stuff like that.
In a lot of ways that abstraction is actually not beneficial because those classes probably only appear in your project once because you're not creating tons and tons of different nav bars. You have one main layout file with a nav bar appears once. So if the class is only used to single time, then you're not really buying yourself anything by trying to bundle all that up into some abstraction. It's sort of like the point of having that navbar class is, well, what if I want to create another navbar?
I don't want to have to duplicate all these styles again. I want to have a single source of truth for that. But the reality is your layout file is actually the single source of truth for that. And if inline styles had the necessary functionality to do it, you could have just used inline styles for that whole thing and never felt any pain points because you would never be trying to keep the padding on the navbar in sync across six different pages because it's already all co-located into one place.
As soon as we started using server-side includes to make sure that you had the same footer on every single page, those types of problems disappeared anyways.
**\[09:15\]** **Mike:** Yeah. So there's a lot of developers who are reluctant to use tailwind because of the class soup and things like that. What would you say to them to encourage them to give tailwind
**\[09:31\]** **Sean:** a shot? And actually just before you answer that, I guess I would say, do you really care? How much do you care that the world adapts tailwind and starts using it? You know what I mean?
**\[09:43\]** **Adam:** Yeah, it is an interesting question. I try less hard now than I did in the past to convince people that it's a good idea. I think that the honest truth is that it's almost impossible for someone to give in to you that it's a good idea. It's such a polarizing looking thing.
I had seen tools like Till and even before I started working on Till and you know like Atomic CSS already existed. I'm tacky on existed which you know I'd never used but was actually honestly introduced to it after I'd started working on Till and but even I was just kind of like oh that looks pretty nasty and it wasn't until I basically accidentally created something in the same spirit myself that I realized, okay, well, actually this is pretty awesome.
So I think the only way to really change your mind about it is to try and build something with it. You have to just force yourself to do it and just try to silence that voice in your head that's saying everything about this is horrible and wrong. And just kind of like what I said earlier. And just force yourself to do it and find out if it's if it's for you or not.
And I think the that most people who do that that I've spoken to are surprised by how much they enjoy the workflow and how many things they sort of didn't realize were sucking up all of their creative energy when they were doing things a different way. The naming thing is the classic one.
The fact that if you're trying to use an approach like BAM or something, you feel like you have to come up with basically this bespoke name for every single thing. Should this be a block or should it be an element? What should it be called, though? I need to add a wrapper around this. Now I need to come up with a name for that. What should that name be? I don't really want to put the word wrapper in the name because that's kind of a presentational or, you know, it's just like an exhausting war with the trying to name things and then specificity and stuff too is a problem I was just thinking about this this morning that I'd kind of forgotten that that's even something that people bump into and have to fight against when they're they're working on projects written in different ways where, okay, I have this thing, I have to change the padding on it, okay, I'm going to try and change the padding on it but it didn't change or why didn't it change? Oh, there's this other rule that's like five nested selectors deep that happens to have a higher specificity.
**\[12:33\]** **Mike:** That's actually the issue I had with Bootstrap and Foundation. If I wanted to customize the nav, I had to write selectors with like eight different classes before I could override it or use
**\[12:45\]** **Adam:** the important egg. Yeah, so problems like that kind of go away and just the overall speed that that you can work, it's almost concerning how fast you can work. I find I feel like a common sort of concern people have is they feel like they're creating a big mess, right? Because they're working so fast and not putting in the effort to organize things and sort of future-proof things and stuff like that, they feel like when they come back to it, it's just gonna be this giant mess and they're gonna have no idea what to do with it.
but the really crazy thing is that the exact opposite is true. I find like the more organized your CSS's and the more you try to keep the HTML clean, the harder it is to come back and change things. Whereas you got 10 classes on an element and you want to come back and change the padding. Well, there's the class right there in your face that was setting the initial padding, changes to a different class. Now it's done and you did nothing that could have possibly affected anything else anywhere on the site, because it was such a localized change.
Yeah, it's interesting because I've never been able to come up with a good analogy because I feel like that's usually helpful, but I've never been able to think of another example of something where on the surface level, it looks like a total mess, but in practice, ends up being way easier to work with even over time. For me, obviously, I'm biased because I made the tool, but I feel like my tailwind projects are the only projects I can come back to after two years of not working on them and be productive instantly in terms of trying to make it change, you know?
**\[14:35\]** **Sean:** Yeah. I think one of my favorite, one of my most popular tweets that people have liked was I said, The first time, something like, the first time you begin to love Tailwind is when you use it. The second time is when you go back to a project when you didn't use it, you have to update
**\[14:55\]** **Adam:** it. That's when you really appreciate it.
**\[14:57\]** **Sean:** Yeah. Yeah. Because I've done that. I've gone back to old projects where I was using, you know, SaaS or whatever, and sure it's organized as much as it could be, but man, yeah, just figuring out, well, how many things is this thing a fact? And is it an important thing, you know?
**\[15:13\]** **Mike:** Yeah, it is, it is not fun.
**\[15:15\]** **Adam:** You have to relearn the entire CSS architecture of the site every time. It's like a whole new sort of structure that you have to re-download into your brain. Whereas if you're just using Tailwind from project to project to project, the keeping those kind of muscles fresh on the project you're just working on right now is keeping you able to edit the project that you worked on six months ago or a year ago
**\[15:46\]** **Sean:** because it's all the same. Yeah, and it's even more if you're working with other people. Like if someone else also uses tailwind, like I can Sean and I can hop in projects to get there's no need to educate anyone about what system you're using this and that it's just oh well.
**\[16:03\]** **Mike:** We don't have to worry about different conventions, which is what we had an issue with Before we started using tailwind because I did my CSS conventions different than might it.
**\[16:12\]** **Sean:** Yeah, and if we worked on a project together, it would be like, well, how do you do this? And now it's just like, even if you don't use tailwind, you can look at it, look at the markup and tell exactly what's happening for the most part. Like, you see, underline, oh, that's probably
**\[16:25\]** **Mike:** underlined then. Yeah. Yeah. I also like that you set it up so that you can do variants like hover states and dark mode and it just you prefix it with hover colon and then on hover my link changes color or the underlying appears or whatever. It's really a very clever way to do that. I can't even imagine how difficult it was to program it to work. Yeah, I mean, it's pretty simple
**\[16:55\]** **Adam:** at the end of the day. I think the first time I'd seen that was Bootstrap and they didn't do it with with stuff like hover, but they did it for breakpoints. So when you're building your grid with Bootstrap or something, you might say call six, call SM3, call MD2 sort of thing. And it's the same general idea of basically saying, apply these styles conditionally at this breakpoint and just expanding that to also any other conditional states you can think of. So instead of writing a single class that sets a background color and then on hover that class also sets a different background color, you just use two classes. One that makes the background dark blue and then one that makes the background lighter blue on hover.
Yeah, and it's pretty crazy what you can do with that stuff. And that's one of those things where a common criticism is like, well, this is inline styles. Like, why would I use this instead of inline styles? And the main benefit is that there's CSS features that are just literally not exposed to you within line styles, which are things like hardware states, focus states, media queries, all that sort of stuff you just straight up can't do within line styles.
I say this to people all the time that if inline styles did support that stuff, I feel like I probably would just use inline styles instead of using tailwind. It would be a lot more verbose, but there's something pretty compelling about not having all that's tooling to worry about and all that stuff, you know, maybe I have to write twice as many characters, and I'll just use CSS variables to kind of capture my color palette and all that sort of stuff. But that doesn't exist, so, you know, is basically an attempt to supercharge inline styles.
But the other side of that is of course a lot of people will just say in line styles are bad in general because we've sort of been conditioned for the longest time to feel like you're not supposed to put styling information in your markup. So it takes sort of first accepting the fact that actually that isn't as bad as we thought and can actually be a really productive way to work and once you've accepted that then it's just about figuring out what are the limitations of in line styles and how can we solve those. And that's basically what tools like Tailwind are trying to do.
**\[19:26\]** **Mike:** Yeah. Yeah. Yeah. I think you solved it. Alligant leads. It's really amazing what you've been able to do. And especially in Tailwind 2, you brought out a jet just in time. And that was a massive improvement there. And then And two or three weeks ago, you released Tailwind 3. And with that, now you've got stacking variants and a whole whack of other amazing features. How did you decide what to include in Tailwind 3? And is there anything left for you to do?
**\[20:07\]** **Adam:** Yeah, I mean, the big thing for Tauin 3 was making the new JIT engine, the default, because that solved a lot of issues that we were running into. One of the biggest problems we had was every time we added new features, the development CSS file size was getting bigger and bigger. And for a while, that wasn't really a problem. It was okay to have like a two and a half megabyte CSS file like browser didn't really have any problem with that.
in a production, you would just purge that so you'd only be shipping the styles you actually used. But as we were adding more and more stuff, it was getting to the point where even the development build size was causing problems. And some of the issues were like the browser was just parsing the styles really slow. So if you open up the DevTools and you were toggling styles on and off, there'd be a delay.
And that would get worse and worse. The more features you enabled until end, So that was no good. And then the other issue was just that taking like a four megabyte CSS file and funneling that through your build tooling, like through webpack and all that stuff, those tools are just not, they're just not expecting to deal with files that big. You know, and they're not built for that situation or optimized for that use case, which is totally reasonable and justifiable.
You know, Why would you be optimizing for dealing with a four megabyte CSS file? So you could get really slow builds as it tried to do all the work that it needed to do to produce the bundle. So the GIT stuff was a way to keep the CSS file size small, even in development by just generating the CSS that you need in the first place, instead of generating everything up front and then purging everything. And by doing things that way, we didn't really have to worry about there's a lot of decisions that we had to make before that where only certain variants were stackable.
So you could do like LG, colon, hover, colon, whatever, but you couldn't do hover, colon, focus, whatever because we kind of considered those at the same level in the hierarchy. We had like three layers of variants. I know it's maybe this is deep in the way, these are super technical, but with the JIT stuff, none of those constraints existed anymore. So we were able to add variants for all sorts of stuff.
We didn't have before. Now we can add more breakpoints if we want, and it's no problem. We added more colors by default, and it's no problem, because the development file size is never big. And it's way faster to, especially when you're funneling it through other tooling, because now Webpack only has to deal like a 30 kilobyte CSS file instead of a 4 megabyte CSS file.
Yeah. And yeah, and it let us do some other cool stuff, like one of the complaints we used to get was, a complaint is a strong word, but sometimes you just need to do something that someone doesn't have a utility for. Like you're building a marketing site, there's some background image that's positioned in this like very specific pixel-perfect way with like top, negative 117 pixels and write whatever You know, and all the stuff in tailwind is constrained in this very sort of like design system oriented way where it's a spacing scale that uses multiples of four that gradually space out farther as the numbers get bigger and stuff like that. It's when you're trying to build something that needs to be some element that really needs to be pixel perfect.
there was no tailwind utilities built in that would help you do that. So you'd either use inline styles, but then you'd run into limitations like, oh, well, on different breakpoints, we need to change the position of that image. So now you're back in CSS trying to make dot marketing background image and writing all custom CSS for it and stuff. But now that we're generating the styles on demand, we came up with a syntax that that lets you use any value you want with any of the utilities.
So you could say top, yeah, you could do top negative 117 pixels and tailwind will parse it out of your template and be like, okay, it needs 117 pixels, all right. Throw it in the style sheet. Oh, I love this. Yeah.
I started using it. It's funny because we were finding ourselves doing that even before we created the, the Gid engine. It was, we were trying to figure out like, Well, what do we do when we have these custom values? Do we revert back to this mentality of trying to come up with some content derived name for the class, like marketing background sort of thing?
And what we found was working better was just saying, nope, what are the styles that we need to add? Let's create classes that are named after those styles. So you can see even on, like I think, the Tailwind V0 website, there's some custom classes that do really weird things, that have question marks in them and stuff, because I was trying to figure out how to, in that case, it was before position sticky was really well-supported in browsers. So I wanted to add a different margin to the top of the sidebar, whether position sticky was supported in the browser or not.
So we had to use the add supports rule. So I was trying to come up with some class name that basically codified if it supports position sticky, then add this margin. So the class name is something like sticky, question mark, MT- then in brackets, like screen minus 10 pixels or something like that. So we were already doing that.
Anytime we needed to create custom CSS, we were always remembering, OK, let's name this class as if it existed in Tailwind, not as if it was specific to this project. So this new engine that we're using in 3.0 lets us just kind of do all that stuff magically and automatically instead of having to go to your CSS file and kind of remember to do
**\[26:05\]** **Sean:** that. Mm-hmm. Do you have any, one of the things that I run into, you mentioned earlier about if you open up DevTools and you want to do stuff it was taking a long time before the Gid engine. I find a problem that I sometimes, because I do that too, where I open up DevTools just to play around in that, and the browser. But if it's purged away, some of the classes, I suddenly don't have access to them in DevTools. If they definitely use p-16 in the project, then it's not gonna have an effect. Do you have any, I don't know, recommendations
**\[26:38\]** **Adam:** of how to deal with that, or that's our great question, Mike. That is definitely the biggest downside to not having the CSS generated. It hurts that workflow if you're used to doing that. I don't find it biting me as much now, because I've just sort of trained myself to do it in my editor and rely on a hot module reloading.
That's what I do too, yeah. And then with the Tailwind Tell-A-Sense stuff, and if you're using VS Code or JetBrains stuff has support for that too, you kind of get all that completion and stuff. But it is annoying when you're just like trying to inspect an element and just be like, I just want to tweak it like right here really quickly. I know that a friend of mine, Marcel, was working on a tailwind browser DevTools extension that I think will let you do that sort of thing.
Cool. So it'll be interesting to see what happens there. But that was the biggest tradeoff for sure. But I do think in general, it's just a matter of kind of changing your habits.
Yeah. And the benefits are worth it, I think, for being able to have all the extra features and the speed and stuff like that. But it would be nice if that just magically worked, for sure.
**\[27:48\]** **Mike:** Yeah. So in Tailwind 3, to expand on the, you can set whatever pixels you want, like font-square-brackets, 17 pixels. In Tailwind 3, you add this new option where you could use utilities that don't exist in Tailwind. I forget what it's called, but I found out about it the day was released, but after I finished working, when I could have used it.
**\[28:18\]** **Adam:** Yeah.
**\[28:19\]** **Mike:** And at the same time, I found out that you had added utility for what I was using into Tailwind3, which was CSS columns.
**\[28:29\]** **Adam:** Yeah, nice.
**\[28:30\]** **Mike:** Yeah, yeah, yeah. Which I don't use often, but I since updated that project and adding this things where you can use CSS that's not part of Tailwind, absolutely amazing.
**\[28:44\]** **Adam:** Yeah. It was a weird one because that's really like why are you just not using inline styles because you're literally writing inline styles in the class tag at this point because It's not like margin where we do m-2 and we have kind of our special DSL for it in this case You're trying to use a CSS property that till and is unaware of like a mask clip or
**\[29:10\]** **Mike:** Some other obscure stuff couldn't you wouldn't the adventure be that you could set
**\[29:15\]** **Adam:** media query prefixes on that? Exactly. Yeah. That's the benefit.
So that really is just like inline styles on steroids at that point. But it's super cool because now you at least have a path forward when you do find yourself needing some really esoteric CSS feature that we haven't got around to designing an API for yet. And you need to be able to change it on hover or different break points, or you just simply don't want to jump into a CSS file and start having some stuff in custom CSS and some stuff generated by Tailwind. And it's also nice because now when someone would open an issue or something on GitHub, how come Tailwind doesn't support this, we can say, well, just because we haven't had time to think of an API for it, but in the meantime, if you don't mind writing out the long-hand version of it, you can just use it and it'll it'll just work and you can refactor it to something shorter later if we add support.
But if we don't, it also doesn't matter because that'll just be fine.
**\[30:17\]** **Mike:** That is excellent. I already write very little CSS, but this now just makes it so that my CSS file is probably just going to have the tailwind declarations.
**\[30:26\]** **Adam:** Yeah. And once you're at that point, you don't even need a CSS file because we'll use that as the defaults. Depending on how you're building your CSS, if you're using tailwind CLI, you can just not write an info file, and it'll just use that stuff by default.
**\[30:45\]** **Mike:** Hi, this is Sean. Thank you for listening. We loved getting feedback and topic or guest suggestions from listeners like you to do so. Please visit website 101podcast.com slash contact.
**\[30:59\]** **Sean:** So let's talk a little bit about Tailwind UI. So we mentioned foundation and bootstrap, TailwindUI, in my understanding, is it's more along those lines where it's component-based. If you want a nav bar, it gives you a nav bar, that kind of thing. Would that be accurate? Why did you create it? Where do you see that going?
**\[31:21\]** **Adam:** TailwindUI is a giant directory of nicely designed, well-constructed examples of different UI patterns that you might want to build and use them on your projects. And it kind of came to be because yeah, a lot of people don't have design chops but are still using talent and need some, well, it sounds a few different problems. Like one is just inspiration, you know, and a lot of ways it's, it replaces dribble for some people in their workflows, you know, I don't know how many times I've gone on Dribble to search for newsletters sign up to see what kind of layouts and stuff people have come up with. Yeah.
Telling UI, you can just go there, and maybe we have 10 different ones you can look at or whatever, and get some inspiration that way, so it's useful in that sense. It's nice to just have stuff that's just done and off the shelf that you can just grab and pull in, and because Telling, everything in Telling UI is still built with just raw utilities. custom CSS or anything added. It's all just a default tail and configuration.
So if you grab a snippet of HTML and paste it to your project, as long as you haven't done like really over the top customizations to your project, like we're completely replaced the spacing scale or whatever, even if you've totally replaced the color palette, you're still going to have the bones in place for a well constructed responsive version of this design. And you can just tweak the utility classes to change whatever you want, you know, it's really portable, which is what I kind of love about building things this way. So it's hard to, I feel like I'm probably reconstructing history, or trying to think back to it, but I think it just kind of seemed like an exciting idea to sort of build this directory of things as a resource for Tailwind users. And it was also just a good fit for me and Steve Schoeger, who's my business partner.
Like we wrote the refactoring UI book together. So we were already working on projects together and in business together. And he's a really, really incredible designer. So it seemed like a good way to marry our two skill sets, you know.
We would work together to come up with some ideas. He'd design them, make them look really great, then I would build them. And at the time we were also trying to figure out, like tell when it was growing really fast in terms of lots of people using it, and it felt like there was so much to do still. And this seemed like an interesting path forward to trying to make development on the framework sustainable, because it felt like something we could charge for, because there was already so much precedent of like, you know, it's like theme forest exists, you know, people are happy to pay for well-designed HTML templates, you know.
So that was sort of a hypothesis, maybe we can sort of design some stuff, build it, throw up online and sell it, and that can fund our time to keep improving talent and keep improving the ecosystem. Here's true. I've done that. That's worked out really well.
**\[34:37\]** **Sean:** Yeah. I know that one of the benefits, I don't use Tailwind UI, but I've noticed if I go in and start looking online for what people have done for developing a card, three card row or whatever. Sure. You can just grab the code, put it in, and it will look exactly like that. It's not like, here's a markup, oh, and here's the CSS, and if you want to change it, to match your thing, you've got to go in and dig through, but there's very little.
**\[35:03\]** **Adam:** Yeah, maybe there's a different name and convention than you, whatever.
**\[35:07\]** **Sean:** That kind of thing, I mean, obviously, Tailwind UI would be taking advantage of that ability, which is something that the other frameworks like that don't have, right? We can just drop in markup, and it's going to be there.
**\[35:18\]** **Mike:** Yeah. So Adam, I have a question for you. And I'm not sure exactly where I stand on this. I'm curious what your thoughts are.
I've heard some people say that tailwind is great for people who are new to CSS. It's super easy to use. And I kind of lean the other way that tailwind is better for people who have a very strong foundation and are well versed in CSS. because you still need to know how it works.
You still need to know all the class names. If you're not well versed in it, then I feel like you'd be using probably tailwind UI and just copying and pasting your components, which is fine if that's what you want. But if you want to be custom bespoke stuff with tailwind, I feel like you need a stronger foundation in CSS. What are your thoughts on that?
**\[36:16\]** **Adam:** Yeah. Yeah, I agree with you. I feel like you need to know CSS quite well to be really effective with talent.
**\[36:26\]** **Mike:** Because you need to know what to search for in the docs if you don't, if you can't get the name.
**\[36:30\]** **Adam:** 100%. If you want to build a list with a border around it and lines between each item and each item is like a link that, with a background, just color on hover or whatever, and bootstrap, that's like dot list on the parent, and you're done, and you don't know how that works, which is one of the powers of that tool. But with Tailwind, you need to know a lot to successfully implement that. You need to know the difference between justify items and align items and justify content and place items and all that stuff.
you know, so I 100 percent agree. I don't think you can really succeed with Tailwind without being good at CSS. We try also, though, to make it approachable and we invest a lot in the documentation
**\[37:25\]** **Mike:** to sort of teach people what these things do. Your documentation is the best documentation of any project that I have ever used literally you wrote you guys should write the book on how to do
**\[37:40\]** **Adam:** documentation because it is the best I still think it kind of sucks but we have a lot of work to do still but yeah we've worked really hard you know everything as far as we can manage has a visual example that explains the best we can what that CSS property does. So if you want to know what does a line items do, we have a page that shows you all the utilities, kind of explains some common use cases and gives you visual examples of everything. But that still doesn't help someone who doesn't even know that a line items is the CSS property they have to look for.
**\[38:21\]** **Mike:** And that goes back to what we were just talking about of having a foundation in CSS.
**\[38:26\]** **Adam:** Yeah. And we'd like to get better at that too. Like one thing I really wanted to do for the tail end three release, that I also wanted to do for the tail end two release, about didn't have time then. It didn't have time here either, is to create a whole new section in the documentation that sort of is higher up before all of the individual property references.
It's just like a well-categorized and organized section on styling fundamentals with Tailwind. Because one of the craziest things right now is there's no page in the Tailwind docs that has the title Flexbox because there's no Flexbox utilities. There's the display utilities, there's the justify items to utilities, there's the Flex grow utilities. But there's nothing that you can just go to that's like, this is what Flexbox is, this is what you can do with it, this is how you use it in Tailwind.
**\[39:15\]** **Mike:** Sounds like you want to replicate MDN or something.
**\[39:18\]** **Adam:** In a way, yeah, I feel like we are already of recreating MDN in a lot of ways. But yeah, I would love to have a page for like forms that sort of is a funnel to a bunch of the other features until when it can kind of teach you about the appearance property about stuff like the resize property. So if you want a text area to only be resizeable vertically instead of horizontally. You need to figure out what people are looking for and help them surface the things that they actually need to find from there.
Even a topic like accessibility, like Teowen has so many things built into it to make building accessible websites easier, but they're not grouped together in one single page where you can read about all the stuff that we've built in. You kind of have to find it all scattered everywhere, but we kind of need both, because some people are gonna look for things from one direction, some people can know things from another. And that's something we already try, work really hard at in the documentation. There's so much duplication in the documentation, unbelievable amount of duplication.
Every single page for every utility explains how responsive design works in Tailwind. Every single one. So there's like hundreds of pages that explain that over and over again, because if someone searches Tailwind CSS grid columns and lands on that page, and they want to know how to change it responsibly, I want them to know how to do it from that one page. I don't want them to have to go to the sidebar and find the thing on responsive design that tries to explain it in some abstract way.
I want them to see an example that says, call span four, MD call span two, you know? And we have that for every single utility.
**\[41:01\]** **Mike:** This is exactly why your documentation is so good.
**\[41:06\]** **Sean:** I'm sure it's very frustrating from your perspective to have to create that, but yeah, as a user, it's helpful.
**\[41:12\]** **Adam:** It's a big challenge trying to come up with ways to make that maintain them.
**\[41:16\]** **Mike:** Adam, do you write the documentation yourself or do you have one of your staff do that for you? I write most of it. And you're building out how it actually works. Where do you have the time for that and your family?
**\[41:30\]** **Adam:** I actually haven't built, I didn't build the website. No, like actually Brad on our team built the website. And I did a lot of the writing. And other people on the team worked on other parts of the website. We have a team of eight people now. And all eight of us, well, seven of us out of eight, we're working on the documentation for like five weeks straight now.
**\[41:55\]** **Mike:** Wow, amazing.
**\[41:56\]** **Sean:** Yeah. So Adam, we mentioned earlier that Sean and I are members of a Slack channel, just some web developer, friends of ours, is probably, I don't know, fewer than 10 of us all together.
**\[42:10\]** **Mike:** I think there's nine.
**\[42:11\]** **Sean:** Yeah, so anyway, we are frequently in there talking about various things. And I would say half of us are big tailwind fans that the other half aren't, I'll say. And we don't get into heated conversations, maybe warmed conversations, if you will, about whether or not tailwind is good and this not. But of course online, there's a lot of Twitter and whatnot. There's a lot of people who are pretty passionate about it one way or the other. How do you deal with, as a product developer, you know, just the hate that you can get sometimes for, like, oh, this is the wrong way to do it, all that kind of stuff.
**\[42:50\]** **Mike:** Oh, I was saying Reddit threads where the vitriol is terrible.
**\[42:53\]** **Adam:** Oh, I would say, I would say overall poorly, because I would deal with it, but I try to get better at it. It's, the project is at a point now where, even though it feels personal to me, I know it's not personal to the people who are criticizing it. So you have to learn to try and disconnect that even though it is a challenge. It's a struggle when you invest so much time into building something that you really believe in and you think is like a great way of doing things in people, you know, attack it or say it's terrible or whatever, because it feels like what people are doing is basically saying, well, this was your best idea and your best idea is awful.
So, if the best thing you can make is terrible, then how does that sound when you use a human being? You know what I mean? Like, it's easy to let it get to you that way. But, I don't know, I think it doesn't have to be for everybody, you know, and that's fine.
I think the thing I tell myself or the analogy that I make in my head or to other creative things, like music or something, you know?
**\[44:04\]** **Sean:** Right.
**\[44:05\]** **Adam:** Something could be like my absolute favorite band in the world and there's gonna be people who hate it. And as a person making the thing, when you make an analogy like that, it seems really stupid to spend any time on the people who don't like it. Like they're welcome to not like it, but it's easy to fall into this trap of wanting to make those people happy, they're by adding features that kinda go against the core values of the tool to make it appeal to more people or whatever. And that's like, you know, slay or trying to write a song for Taylor Swift fans.
It just doesn't make any sense, you know. It's okay for people to want things to do things a different way. And I think the thing that makes the most sense for us is to just keep improving things in the dimension that attracted the people who are already here. There's an overwhelmingly positive, you know, but obviously a lot of people don't like it, and it's hard not to let that stuff get under your skin.
Like one negative comment, I weighs a thousand positive comments. That's how it always is. And you just have to train yourself to not care about that. Power of the troll.
Yeah. The reality is like, even hacker news, which is, you know, the most toxic side on the internet, except for Twitter now, I think, is worse now. But even hacker news, when there's a thread about tailwind is overwhelmingly positive, which is like, ooh, this, I don't know what that means, you know? But usually, Hacker News 8's everything.
So I have to focus on that stuff. And yeah, just try to develop a thick skin. It's sometimes you slip up and get defensive or whatever, but in general, you just kind of have to focus on the people who enjoy what you're doing and support what you're doing and recognize that not everything is going to be for everyone.
**\[46:05\]** **Mike:** Right. Now it feels like there's more positive supporters than negative people, but obviously negative people tend to be a little bit more vocal. So on Friday, you posted a tweet and you said one of the hardest things about running a product is learning to accept that there are 1000 ways to improve it. But in the next year you'll be lucky to do 25 of them. Still learning how to ignore everything that isn't done to celebrate what is. So my question on this is how do you choose what to add for tail and what to say for later versions. And I have a follow-up
**\[46:43\]** **Adam:** question after that. Yeah. With Tailwind itself, there's not really a lot of stuff that I have like on my backlog to add. Honestly, the bigger projects are mostly not features for the framework itself but ways to improve the ecosystem in ways to make my life easier in terms of less support or whatever, you know.
It's funny because most tailwind releases kind of happen by accident, like every, every, you know, basically two months, we kind of decide what we're going to work on for the next six or eight weeks. And there's been many times where that list didn't contain any new tailwind features, but somehow by the end of that period, I've released another version of talent with new features in it. So in general, I the things I'm most likely to add are things that I'm just really excited about myself, which I think is the same for how most people work, but then there's also a lot of things that are just commonly requested from the community that will prioritize. At this point, I feel like my focus is on trying to just make the tool as bulletproof and maintainable and fast and stable as possible because I think it solves the problems that most people have.
There are some features we could add and stuff like that but I think we have to be careful to not just keep adding new stuff when we should be investing more in performance and stuff like that. And it's already really fast now that we rewrote the whole thing, but my goal in my head is for Tailwind to be like SQLite level reliable. That's kind of like my internal goal. I want it to be like, if your build fails, I want the Tailwind GitHub repo to be the last place you think you're going to need to go to complain about it right now because it's just has
**\[48:50\]** **Mike:** a reputation for just being bulletproof. So follow up question. What makes something a plugin such as the topography plugin rather than a part of the core package. I haven't said that I recently added the typography plugin to my boilerplate build, so I use it on everything. Nice. Yeah, I think in
**\[49:12\]** **Adam:** general, there's a threshold for how opinionated something is where we just feel like it doesn't belong in core. The typography plugin fits that, in my opinion, because it does so much complex stuff to get your HTML looking nice and relies on hard coding in default tailwind colors and stuff like that. So, if you were to use the topography, if topography stuff was in core and you replaced your entire color palette, then I don't know what it should do, because it can't make assumptions about the fact that the numbers in your gray scale are the same levels of contrast or whatever is the numbers in the built-in one, or maybe you've changed the font sizes. So, do we try and use use your font sizes or do we use the font sizes that we built in by default?
**\[50:01\]** **Mike:** That's interesting because when I build, I don't use the tailwind color palette. I occasionally use the font sizes, but I never replace them. I just extend because part of the build is it doesn't spit out the default styles if you're not using them. And I just like to have them there.
**\[50:23\]** **Adam:** Yeah, so I would say that's kind of like the big one is just, yeah, if something feels too opinionated to be in core or there's, it wouldn't play nicely with lots of customizations without you having to make a lot of customizations, then it feels a little bit weird to include. But there's always a chance that it ends up in core eventually because the other element is do I feel like we're going to want to iterate on this at a different rate than we're iterating on the framework itself and the typography plugin, you know, I still feel like I want permission to be able to make breaking changes to that as we try to improve it. We try really hard to keep things as backwards compatible as possible, but the release that we just did alongside V3 did have a couple of really minor breaking changes that I don't think anyone even noticed unless you were doing certain types of customizations. But it's nice to be able to have the freedom to do that. It was the same with the Forms plugin. The Forms plugin changed a lot between a few versions and is also kind of opinionated. But then the other reason that we often don't put things in core and make them plugins is if we're worried, we would have to make a breaking change to core after adding it to core because CSS added a better way to do that thing. So an example of that is aspect ratio stuff. So there's an aspect ratio plugin for the longest time that used the classic padding bottom percentage hack and absolute positioning stuff that we've all used. But I knew when I made that plugin that oh there's an aspect ratio property that's currently supported behind a flag in Chrome but not supported in any other browsers yet. So if I add the aspect ratio stuff to tell in core, when the official CSS property comes along, it's going to be an annoying thing that we have to change in the framework. So by doing that as a plug-in, that let us add the kind of regular aspect ratio stuff to tell in three. So now if you only need to support Safari 15, which is I think basically nobody, I think everybody still needs to support Safari 14 for probably another six months or so. But all that stuff is just built right in now, replacing the aspect ratio polygon and we didn't have to make any breaking changes to the framework. The same is true of the line clamp plugin. That's another one where it's super bizarre how that you have to implement that using these CSS properties that you don't use for anything else that don't make any sense. We're even using a WebKit prefix to target Firefox and all this weird stuff that makes no sense. But there are like working drafts for a native way to do it. So it's like, I don't really want to build it into core when there's going to be a better way to do it in the future. And maybe that doesn't actually matter. Like the reality is if you were using the old aspect ratio plugin and now you want to migrate to the new syntax, that still affects you the same way of breaking change would. You know, you still have to change a bunch of code. Yeah. So maybe it doesn't really matter. And we should just pull them in. And I've been thinking about doing that with the line clamp stuff. But in general, those are sort of my litmus tests.
It does not feel too opinionated. Is it something that's going to be easier to implement with some new CSS feature that's coming soon? And we should hold off and keep it in a plug-in. Or is it something where I don't feel 100% sure about how the best way to implement it? And I want to be able to make changes to it without having to tag a new major release of tail if we discover some way better API for it or something.
**\[54:08\]** **Mike:** Adam, it's really clear that you think deeply and carefully about everything that you do, and that was a great answer. Truly. I understand you're thinking now, and 100% behind it. I just didn't know why, and I'm really happy with that. So, we're almost done here. What do you see as your next big challenge for Tailwind? Will there be a tailwind for because really tailwind three feels incredibly complete?
**\[54:40\]** **Adam:** I'm sure there will be a tailwind for eventually. My guess is at this point, the next major version of the framework will be driven more by a design refresh than by anything else, like basically changing the default theme. So I think everything that's in tailwind by default still holds up visually right now, but I could see a world where two years from now our shadows just kind of look a little bit dated compared to the way people are designing shadows at that point or our colors are looking not as nice or maybe everyone's standardized on using like the P3 color space or something and we need to adapt to that sort of thing. So I would imagine that that's That's the Tailwind 4 is going to be a new look for Tailwind more so than it is anything else.
And then the nice thing is we can easily ship the old defaults as well. So we'll be able to update to the new tooling, but still use the old design tokens.
**\[55:44\]** **Mike:** Yeah, that's a great idea. It's part of what made upgrading to Tailwind 3 super, super easy, which I did on four projects the next day.
**\[55:53\]** **Adam:** Nice. Yes, I think we, I think our projects are still telling too, but some of the many ways, but we need to upgrade those. Yeah, I think that would be the thing that would drive a tailwind for at this point. I think we've had a point where we can't really do much in terms of really drastic changes to the API or anything.
I don't think there's any value in just breaking things for for people just to make things, you know, slightly nicer. I think over time my standards or my threshold for what warrants of breaking change has gotten very, very, very high because I think maintainers generally underestimate how annoying that is for users and how much
**\[56:41\]** **Sean:** that can slow down the migration process. You get the whole like Python 2 versus Python
**\[56:48\]** **Adam:** kind of a situation where, you know, there's both versions are still in use for like 10 years.
**\[56:56\]** **Mike:** Well, Adam, I'm going to say I never upgraded a bootstrap or foundation site.
**\[57:00\]** **Adam:** Well, you kind of just can't, you know, they're, they're still around. They're still using whatever
**\[57:05\]** **Mike:** version. It's not, not an easy thing even though there is an upgrade guide. The tailwind, I have, I've sites that have gone from tailwind zero to tailwind three. Yeah, yeah. That's a little bit of
**\[57:17\]** **Adam:** of a difference, I think, between telling to another CSS frameworks. We try to try to approach the upgrade story more like you would a library, like react or something where you do always want to be on the latest version, whereas a lot of other CSS frameworks that are really just built around, like, these are the components, this is how it looks, whatever. It's not really a big motivation to upgrade because you don't want to revamp the entire look of your site necessarily to match to match the new stuff and that totally makes sense to me. I think that's totally reasonable.
But yeah, we tried to make the upgrade path smooth so you can still get the latest tooling without having to buy into any a different design or anything which is nice. Yeah, aside from that, like, aside from the tail and four thing, I think the biggest things for us for the new year is I'd like to do a lot more with tail and UI. We've been so busy with tail and three that we haven't made any major updates for a few months now. Like the last really, really big substantial update was in August.
So I'd really like to get back into doing some stuff there. Got a lot of ideas for how we can can make that stuff better. I want to keep pushing on educational stuff. I really want to write that new section of the documentation that I mentioned.
That's something I've wanted to do for a long time, so I hope we can finally get to that. And then a lot of the other things that I want to do are more around making the company more effective, I guess. figuring out ways to make myself less important. Like we mentioned, I'm writing all the documentation and stuff like that.
And I like working on documentation stuff, but it also kind of doesn't feel like sustainable. It feels like we need to figure out better ways to make the company be able to operate without depending on specific people. So a lot of that is more about learning how to better create systems of processes and training resources and figuring out what we're missing in terms of skill sets that we should hire for and stuff like that. And just turn it into a really well operating machine where everyone is working out a nice, calm pace and everything is running smoothly.
And there's no bottlenecks, you know? So that's not as interesting, I don't think, for Dell and users as it is for me, but that's a lot of the stuff that I really wanna focus on in the new year.
**\[60:11\]** **Mike:** I think that's important to focus on your business. That's gonna keep it around and make me happy that Dell one's gonna be here for a long time.
**\[60:20\]** **Sean:** Yeah, definitely makes sense. Well, Adam, this has been terrific. Thank you so much for being here today. We mentioned that you're a podcaster and whatnot. Is there anywhere that you'd like to send people, I mean, tailwinds.s.com, obviously anything else you wanted to let people know about in terms of learning more about what work you
**\[60:39\]** **Adam:** do? Yes, sure. So, probably the best place to keep up with me is on Twitter, so just twitter.com slash Adam Wavin. My podcast has kind of been quiet for about a year now, but if you are interested, there's still lots of good stuff there if you want to dive into the archives and look through stuff that's at fullstackradio.com.
But aside from that, yeah, just Twitter and tellincess.com and that's where you can kind of keep up with everything I'm doing there. And our YouTube channel, I guess, is probably the other place. So YouTube.com slash tailwind labs try to put up new stuff there every couple weeks.
We'll put all this in the show notes too. Sounds good. Excellent. Excellent. Adam,
**\[61:17\]** **Mike:** thank you so much. This has been an excellent conversation, very informative and fun. Yeah, thanks for me. The website 101 Podcast is hosted by me, Sean Smith. You can find me on LinkedIn. My username is caffeine creations or on Twitter where my username is caffeine creation, C-A-F-E-I-M-E-C-R-E-8-I-O-M, or at my website caffeine creations.ca.
**\[61:50\]** **Sean:** And by me, Mike Mella, you can reach me online at belegwater.ca and also on Twitter and LinkedIn where my username is Mike Mella, that's M-I-K-E-M-E-L-L-A.
Close Transcript
Have a question for Sean, Mike, and Amanda? [Send us an email](/contact).
[](https://www.google.com/podcasts?feed=aHR0cHM6Ly93ZWJzaXRlMTAxcG9kY2FzdC5jb20vZmVlZC5yc3M%3D)[](https://itunes.apple.com/ca/podcast/website-101-podcast/id1449510012)[](https://open.spotify.com/show/3rmSM1R9t6q1U8DmYWJRSO?si=NrYPMgDaRV6Dd56PjEaPow)### Season 05
- 1 [ Meet your Host - Sean](https://website101podcast.com/episodes/season-05/episode-1/meet-your-host-sean/)
- 2 [ Meet Your Host - Mike Mella](https://website101podcast.com/episodes/season-05/episode-2/meet-your-host-mike-mella/)
- 3 [ Wes Bos - Your Web Boss](https://website101podcast.com/episodes/season-05/episode-3/wes-bos-your-web-boss/)
- 4 [ Tailwind CSS with Adam Wathan](https://website101podcast.com/episodes/season-05/episode-4/tailwind-css-with-adam-wathan/)
- 5 [ Starting my own Website with Bill Campbell](https://website101podcast.com/episodes/season-05/episode-5/starting-my-own-website-with-bill-campbell/)
- 6 [ CSS is Awesome with Kevin Powell](https://website101podcast.com/episodes/season-05/episode-6/css-is-awesome-with-kevin-powell/)
- 7 [ Meet Your Host - Amanda](https://website101podcast.com/episodes/season-05/episode-7/meet-your-host-amanda/)
- 8 [ 11 Things to avoid doing on your website](https://website101podcast.com/episodes/season-05/episode-8/11-things-to-avoid-doing-on-your-website/)
- 9 [ Vanilla Javascript - Fundamentals before Frameworks](https://website101podcast.com/episodes/season-05/episode-9/vanilla-javascript-fundamentals-before-frameworks/)
- 10 [ Hiring Junior Devs and How to Stand Out from the Crowd](https://website101podcast.com/episodes/season-05/episode-10/hiring-junior-devs-and-how-to-stand-out-from-the-crowd/)
- 11 [ AlpineJS with Caleb Porzio: Lightweight javascript in your markup.](https://website101podcast.com/episodes/season-05/episode-11/alpinejs-with-caleb-porzio-lightweight-javascript-in-your-markup/)
- 12 [ Contract Opinions From Not a Lawyer](https://website101podcast.com/episodes/season-05/episode-12/contract-opinions-from-not-a-lawyer/)
- 13 [ Talking to a New Dev](https://website101podcast.com/episodes/season-05/episode-13/talking-to-a-new-dev/)
### All Seasons
- [Season 01](https://website101podcast.com/season/01/)
- [Season 02](https://website101podcast.com/season/02/)
- [Season 03](https://website101podcast.com/season/03/)
- [Season 04](https://website101podcast.com/season/04/)
- [Season 05](https://website101podcast.com/season/05/)
- [Season 06](https://website101podcast.com/season/06/)
- [Season 07](https://website101podcast.com/season/07/)
- [Season 08](https://website101podcast.com/season/08/)
- [Season 09](https://website101podcast.com/season/09/)
<!\[CDATA\[YII-BLOCK-BODY-END\]\]>