This new Tailwind feature is scarier than I thought

in case you didn't know somehow I'm pretty fond of Tailwind it wasn't always that way though when I first saw it I had the same gut reaction most of the haters do it seemed like a terrible way to ruin your HTML and make your CSS harder to build and maintain and I like many of those people was very very wrong all of that said there are some problems with tailwind and there's one person in particular I actually trust to give us this information his name is Nan he's the creator of stylex and if you've seen

my coverage of dialects you might know how much I respect him and the work he is doing to make really really good performant and safe methods for styling your applications and it's not some crazy theoretical stuff either it's what meta uses for all of their styling across their apps nowadays he knows his stuff and I've had a video planned for a while where I was going to go in depth on his handful of small but meaningful critiques of Tailwind but I haven't gotten to it because uh you've seen the schedule I'm busy but now I

have a reason to a very very fun reason Naman put up a blog post his thoughts on Tailwind 4 and for the most part they are very good thoughts but there is one big thing he's concerned about and I think it is worth all of us considering because it's great as Tailwind V4 is there are changes that are worth being a little concerned about at the very very least making sure you approach these new features with a bit of caution a lot of y'all accuse me of being a paid shill for Tailwind they've never given

me a scent but we do have bills to pay so before we cover this let's hear from today's sponsor really fast today's sponsor is code rabbit and you're going to wish you set them up earlier because I know I did I could show you the homepage and all their marketing mumbo jumbo but i' rather just show you what it's actually like having an AI bot do code review and sumar reason help you with your PR process I have a bunch of random PO requests open here that we've had code Rabbit running on like we do

for all of our Cod at ping and it's been really solid here's a fun simple one and also this one's on our open source repo so if you want to go look you can and it's free for any open source users so everything you see here is included in the free tier you see that it's summarized his pole request it described all the new features being added via this poll request it called out some bug fixes as well as all of the test changes that occurred too and if we scroll down here we get the

best part the walkthrough this goes in depth on what specific files changed and what changed about them this is super handy especially on big PRS like the one I'm about to show to have a quick summary for every file on what changed and why it's just a really quick way to get through and they even tag in related PRS so if you have anything going on around the same time super super handy it's been great to work with it also leaves comments on individual lines that it thinks can be changed so here it said that

it thinks this type could have Js doc on it so that when users see it it' be a better type it even has a one-click button you can press to automatically apply the diff on GitHub so you don't have to go write the the code yourself and your editor you can just click a button and it applies the changes and I've been surprised at how many of these changes actually end up being useful thank you code rabbit for sponsoring today's video check them out at soy. link and use code Theo 1M free for your first

month for free the tail end CSS V4 beta was just released and I wanted to share some thoughts on it more specifically I have some concerns that I have not seen covered elsewhere that's what we're here for rather than provide any highle insight let me address the various changes in Tailwind 4 individually disclaimer these words are my own and do not represent yep you get the idea this is n man posting giving us awesome free content and I appreciate him immensely for it he's also in chat thank you for being here you've probably seen his

name pop up in a bunch of videos because he's very quick to correct anything I get wrong about build tools and styling in general that's good anyways first point moving to lightning CSS the move to lightning CSS is a good move the JS Community is largely moving to rust based tooling and being on Lightning CSS will help Tailwind easily integrate with various tools performance improvements are stantial but they aren't particularly important Tailwind jit was already really fast the biggest benefit of lightning is the unification of Tailwind Imports and syntax lowerings not having to manually configure

the auto prefixer is a big one the the amount of with like post CSS and the prefixer and all that so happy is gone CSS first configuration there is much excitement about the CSS first config I don't think this is as much of a slam dunk as many others it has trade-offs the big benefit is the need for one fewer boilerplate files for getting started the downside is that most most of the config is custom syntax that's specific to tailwind and it's no longer types safe hopefully tooling will help bridge that Gap this is a

fair point for a while this Tailwind config wasn't type safe we found ways to fix that with type declarations like the JS doc syntax to import the types from the Tailwind config then we were able to do a typescript which was nice now we're losing all of those benefits by doing it in CSS but apparently you can still import the old JS config by importing it with at config the Tailwind config JS file didn't know you could do that that's funny I might actually end up doing this because I like my type safety anyways and

Nan calls out this should probably end up being a good move in the long run I largely agree CSS theme variables this is where the concerns start architecturally using real CSS variables is an obvious win however in practice using CSS variables can have some surprising performance pitfalls performance issues are inconsistent and when using a bunch of variables to find on rout the impact seems to be minimal but when you reassign them or Define variables on another element in addition to root it can have significant performance impacts if you want proof these problems are somewhat serious

you should check out the last video I did on Tailwind which was Tailwind broke but it's not their fault that video is about how the highlighting on a bunch of websites using Tailwind broke when you drag and select stuff because they styled it with variables and chrome in efforts to make performance better change when and how they resolve CSS variables in a way that caused them to break for text highlighting if you DED them in the specific way Tailwind did the reason that happened is because Chrome wants to improve the performance of these things wherever

they can and they made a shortcut they thought was safe that turned out it wasn't and they had to revert those changes they're not doing that because they're evil or they're dumb they're doing it because they want Chrome to perform well and these things have performance impacts n man does couch this reservation though so as long as most devs don't go overboard with custom scoped overrides for variables things should be okay it's also possible to config Tailwind to inline the variable in the CSS output just like Tailwind 3 and earlier most devs configure their themes

globally and scoped overrides for the variables aren't a common use case so I wonder if inlining variables would have been a better default very fair point native CSS Cascade layers this is an unmitigated success and an obvious win my biggest surprise was to learn that this wasn't already the case there are certain older browsers that don't support Cascade layers but it's a simple polyfill to fix that this is why we like Nan this is the at layer rule in CSS thank you for the clarification I would have spent way too long trying to figure that

out anyways simplified theme config a bunch of values that were previously configurable now just allow arbitrary values like grid calls 73 without the need for 73 to be in Brackets this is a good move and it removes unnecessary boiler plate and friction I will take the stance that this is not necessarily an outright win I'm one of those people that read the book that the Tailwind authors wrote what was it called again refactoring UI apparently they sold a whole bunch of copies of this book when I mentioned it in the past they've never paid me

they gave it to me for free which was cool it's worth a read if you're an engineer that wants to make your design suck a lot less I learned a lot from this they wrote it before they'd even made tailwind and it's actually kind of fun to read in retrospect because it shows a lot of how Tailwind was made and one of the decisions they made in this was to limit the options to a compatible set of things like sizes border sizes colors and all those things but to intentionally limit it not to a super

limited subset but a meaningfully limited subset what I liked about the bracket syntax is it made it clear when you were exiting the subset that had already been built into Tailwind so if you had a size that didn't perfectly fit the scope and the like different sizes that exist within Tailwind you had to indicate that using the brackets as a compiler feature as a thing they to implement all that stuff I don't have a strong opinion on that what I cared about was the clarity in the things that were using the built-in system versus the

things that weren't and losing that was something I'm not super hyped about there's a good point from n man here which is that for things like the number of columns that's not part of the design system but for sizes colors Etc this is different and I totally agree for columns this shouldn't have a different syntax if you're using a column number they didn't prepare for but for sizes and paddings and all those things it I liked the brackets there are more obvious wins though like automatic Source detection built in at import support built in CSS

transpilation Dynamic spacing for scale P3 colors container queries and 3D Transformations which is actually as you probably saw in my tailin 4 video really cool stuff I like this call out here because the tailin docs have all the cool things you can go there or go to my video he's going to focus on what he finds controversial starting with gradients Tailwind 4 finally add support for radial and conic gradients while this is an obvious Improvement I think Tailwind has never handled gradients well coming in hot and I agree I've actually always been pretty annoyed with

the syntax four gradients it just felt kind of arbitrary and all okay getting real spicy it's not something that belongs in the HTML directly I thought I was going to think about that longer than I did I agree these are the points where I'm like okay fine open a CSS file to be clear I know I'm not in the same camp as a lot of the Tailwind Fanboys here once the Tailwind gets complex like this once you're making a lot of different conditions or doing a lot of bracketing or crazy animation stuff just write the

CSS in a CSS file it's fine or as Nan calls out in my chat this is something that should be in the design system like all of the other tokens yes you should be able to set gradient as part of your config and then call gradient Das activated or gradient Das brand not from Indigo 500 via Blue 400 to teal 300 you should not need these three classes to be copied and pasted cu the the copypaste aspect of Tailwind is really really good when the concerns are within the same file so if I have like

four nav links that are hardcoded using the same seven Tailwind classes for all of those is fine because I can select and replace them all there a gradient like this is going to be used in a small number of places that are very far away from each other in your code base I would like it to have a name it is what it is anyways also they use CSS variables to do this under the hood which is kind of problematic tailin should ship with a set of predefined beautiful gradients that can be used out of

the box and let devs Define their own gradients in the config file I agree fun fact that I brought up a few times I spend a lot more time in the Tailwind docks when I'm using a non- Tailwind project because I go to is a reference for the CSS that don't feel like writing so I can copy paste that over to whatever code base I'm working in and the part I spend the most time in see if it comes up look at that second result for most Reon customizing colors because I am in this page

all of the time just to grab good compatible colors what if they did this for gradients what if they gave me some default gradients that looked fine I would use those all the time anyways and as n man calls out this isn't a new problem it's always been this case but you can do it in a config file if you want to probably should just do that the new notar and instar variants tail one's added support for not and hover star with the new not and in variance so now you can say if not focused

make the background Indigo and in Focus make the opacity for this 100 as long as it's within a focused element these are good improvements and are good ways to maintain the guarantees of atomic Styles Oh I thought you might talk some on these cool yeah good I liked these a lot and here's the part that I started getting skeptical of myself where you could control specific children I guess you feel similar Nan these variants are slightly problematic they let you use inert and nth child selectors in your class name this encourages the same bad practice

that Atomic CSS in general inail in particular has always discouraged to be clear what this means is the thing that made Tailwind in atomic CSS great is it killed a lot of cascading behaviors where you weren't writing CSS to try and affect the element underneath in very specific peculiar ways the element being styled and its styles are a lot closer together when you use Atomic CSS these rules make it more likely that you're defining the Styles outside of the element being affected which is going to make your CSS harder to maintain almost always and another

good call it from n man it makes it less reusable because an element Can't Be Moved somewhere else and expected to behave the same way it also makes it less clear like let's say you have a parent component that has an nth rule on it and then the child component is in a different file styled separately if you're in that file and you're trying to figure out why this item in a list is being styled weird and you're in the file with the item from the list and it just doesn't have that CSS in there

at all it's really confusing you go to the browser tools you investigate it you look at the class names and you see it's being applied by the parent you realize you're in the wrong file the whole time it sucks it's not fun and I didn't realize how much time I was losing to those types of things until I moved to tailwind and the style was always in the file where the component was that was a huge huge win for the maintainability of my code bases and this steers us away from that in a method that

is concerning descendant variance there are many celebrating the destruction of atomic CSS guarantees but I think this is probably the most harmful addition to Tailwind ever oh boy coming in hot before we do that though there's a good call out here like for the previous one the odd even use case is a good example of why you would want the nth style rule in the parent here this is nice because you can have every other child be like darker and lighter for a table and stuff like that so that's cool there is no similar justification

for the star variant here the star variant for targeting direct children was already added and it was problematic enough here is star C in P4 now all of these elements get a P4 padding again imagine these elements are coming from a different file and you're trying to figure out where their padding is coming from and it turns out it's here that sucks but the double star is way scarier I like Nan's phrasing here styling at a distance this is the enemy of maintainable styles if the style is too far away from the element it's affecting

it makes fixing things that are wrong way harder and as he says here at least with the star it was containing limited to direct children the double star variant ruins that completely now we have double star colon data- Avatar colon rounded full now any sub element anywhere below this div if it applies data Avatar it's going to magically get this style for you CSS Die Hard have been doing this stuff your whole life you might be like yeah that's how CSS works for the people who live in Tailwind you might see why this is weird

and scary you apply your styles by applying your Styles and realistically speaking if you have the type of control to apply data Avatar here you also have the control to put rounded full on it there's no reason you should abstract that up here other than to be a good CSS cascading Citizen and I just don't think this is good as Nan says other C power I see chaos Tailwind has finally jumped the shark and added essentially all of CSS into class names this is no longer Atomic CSS bars out here this is no longer Atomic

CSS and developers will abuse the hell out of this and run into all the terrible problems that Tailwind was saving them from in the first place there is still time this feature should be rolled back before it's too late bold do I think this should be rolled back okay here is my my middle ground take on this the cases where I see this being useful are cases where you can't control the sub elements like if you're loading data from a CMS or something that is HTML in those cases those very specific cases this could be

very useful because it is such a specific case I think this should be hidden under a flag similar to like dangerous set inner HTML because funny enough the case I was just describing like HTML coming from a CMS you have to Dangerously set inner HTML there anyways so if this was dangerously Target all sub elements then I could see this being okay to leave in but this just being there as part of the default Tailwind experience is going to result in people thinking that doing this is just as safe as doing this which is just

as safe as putting P4 on all of the liis yourself if there is no clarity as you're using it that this is something to be cautious of then it will be used by default the same way all of css' defaults are used already and part of why Tailwind is great is it keeps away some of those features in CSS that that make your code way harder to maintain but if Tailwind adds in enough of CSS you'll end up in the same place so I fundamentally disagree with this message aurus it's a feature like add apply

some people use it some don't the difference there is that add apply isn't one of the Tailwind class names it is a feature that in a different file for a different use case enables you to write Tailwind a certain way there is some clarity admittedly not enough but there is some clarity that add apply is not part of the default core tail and experience because it's not in the place that you're writing it it's not where you're writing these class names in your code it's somewhere else and it's I think become clear enough to the

community that ad apply is not recommended and on top of all of that the Tailwind team has directly expressed that they regret adding ad apply to Tailwind so the only part I agree on here is that it is like out apply they shouldn't have added it or at the very least they should have put it under a conf fig that makes it clear as hell that you're doing something dangerous there's another good point from YouTube chat rare but nice to see this is dangerous especially for people who are new to Tailwind that are coming from

CSS they're just going to repeat the patterns that they're used to instead of embracing one of the core points of Tailwind fully agree n man called out here that he sees this elsewhere I think Adam knows better but he got bullied by the community and in this case the community is wrong one of the things that I think made Tailwind so great is that it ignored the community if Tailwind listened to the haters and the people saying it should do things differently or not exist Tailwind just wouldn't exist if you listen to the push back

on your strong opinions you don't make Tailwind I think some of those opinions were worth walking back like adding the bracket syntax was a huge win in so many ways even if I don't love it most of the time the double star is just kind of dangerous there are more things here and this is nice these are the things that I've wanted to talk about from n man's short pointed critique of Tailwind that I haven't had a chance to and now I finally can the class names could be better this is this call out blew

my mind when he first told me about it Tailwind usually has a prefix in the class them to suggest the style being applied so BG red 500 the BG means background color m- smm is for margin PT is for padding top Etc but there are certain class names where that's not the case like Flex and grid and even something like text which can apply a color or a font size in recent versions this has become even more common with grow and Shrink replacing Flex grow and flex shrink respectively when I saw this I knew you

were going to do something Nan because I remember this conversation and when I saw this change I was like oh they're going backwards not forwards here you might be confused why does this matter why do we not like this these changes are good for previty but they do introduce confusion and they can have a significant impact on code size but the biggest part is the runtime cost if you use a tool like Tailwind merge and you you have let's say a button that has default things in it like you have a default background color for

your button but somebody can override it because of how CSS works the order you apply class names doesn't matter I have these two elements in HTML div class name AB high div class name ba High 2 if I add a background color blue they both become blue what happens if I add background color red I fix that they both become red because CSS doesn't give a what order you apply the class names on the element all it cares about is the order that they exist in the CSS this sucks so let's say you have a

component that's button Class B but you want the user to be able to override this and give it a different background color if the background color they give occurs earlier in the CSS it doesn't work you can't just add new class names you have to be careful and make sure you remove B if you want to apply a if we did this this way with these prefixes and I passed BGA to this component I could quickly check and see if any other things have the same prefix and if they do I can remove them so

that I don't have to deal with this conflict but what if they were named Flex and grid now I have to have a custom path that makes sure if I'm applying grid that none of the other things that conflict with it are applied to the element you can't do a simple prefix checking you have to do a lot more work and the result is that things like Tailwind merge are slower than they should have to be funny enough the Tailwind team actually tends to discourage Tailwind merge and they expect all styles to be applied statically

but that that's not realistic like almost all of the biggest uses for Tailwind are using Tailwind merge it looks like over a third of Tailwind projects are using Tailwind merge you can't pretend it doesn't matter and that is a very good call out their solution is to not merge classes and manage conflicts with important calls it's to style things Based on data or ARA attributes and just handle everything declaratively with CSS I do not like this solution this makes your components way less reusable and it hurts another good call from Deon is that not everything

uses Tailwind merge a lot use class names or clsx or CN instead and they end up dealing with inconsistency a bunch when they develop and obviously both n man and I fundamentally disagree with that approach not only does it bloat the amount of CSS it it makes the logic parts of your component less reusable because the Styles get too closely baked in yeah native tail and merge and class variance Authority would have been a better addition for V4 than the double star I totally agree I'm going to drop a real hot take right now a

lot of Tailwind success comes from the fact that components in react don't have a good style Solution by default there is no good way to style things within react but the component model was so powerful that we went with it anyways we invented a bunch of different waysin the react ecosystem to do styling that varied in their quality but Tailwind as a modern Atomic CSS solution gave us a really happy path for component-based styling without having to leave the react component model react is in arguably a huge part of why Tailwind was successful I don't

think the Tailwind team would disagree if they do hit me up I'm down to chat but there's another important detail here the Tailwind team doesn't like react the tail team are very PHP and rails pilled they come from those worlds a lot of their stuff is still using that they don't love this way of doing things react is a huge part of why Tailwind successful but react is not a thing that Tailwind wants to concern themselves with if they don't have to because of that things that are really reliant on like client JS and client

interactions tend to be less the priority of the Tailwind team in some ways it's the same reason they're moving to CSS for config instead of JS they don't want to be a JS library npm is just the best distribution meth me for what they're doing and what their goals are they don't want to think about client side JavaScript at all they don't like it and that's fine I get it I understand it but yeah and I like this point from n man tailin merge doesn't make sense to be part of tailin because tailin is language

agnostic tailin merge needs to be implemented for each language because it's a runtime function to be fair the language is Javascript but yeah and if you end up using their way of doing things too much the CSS will bloat and that will affect performance absolutely agree yeah hopefully that helps clarify why these prefixes would be very helpful in the man's words I think Tailwind should make it easier for tools such as Tailwind merge to exist and be as performant as possible as a side effect it might also make the Styles easier and more consistent to

read and work with I agree and finally we have the rampant usage of REM units it's easy to change the defaults in Tailwind but the default theme uses REM units for absolutely everything from font size to spacing and from sizing to Media queries designers love this is it lets them maintain their previous proportions but this is actually an accessibility anti pattern when browsing a website the user is able to control sizing in two ways this is really important I only learned about this by talking with them on you can do page Zoom which I do

all the time you can also change the default font size when I learned this I mean I knew this already but I had thought about it for a while when I relearned this I was really excited because I like big fonts especially when I'm reading stuff for content so I went and I changed the default font size in my browser to be large and it broke so much because REM is based on the default font size so if you change your font size it changes everything as n man says here it basically just changes font

size to be a different way of zooming instead of it being just the controlling of how big your font is this is user hostile and it forces you to perhaps need slightly larger text to be able to read comfortably in order to be forced into a layout mode for smaller screens with less density yep totally agree the default value for spacing sizing and media queries should all be using pixel values and not REM which should only be used for font size yeah hopefully you guys are seeing why I like n man's takes he's not saying

Tailwind is bad he's actually chilling the best parts but is calling out how some of those parts are being damaged by specific decisions as well as the costs of previous decisions that don't seem like a deal until you think about this deep enough apparently there are cases where height should still use Ram especially if it's like height for a container that a font in it because the height needs to match the height of the text totally agree rare cases that should have their own like if it was HF like height for font or HT height

text or something like that like if they had a height thing specific for that that was REM everyone's happy so that's he the conclusion well it's post happen to focus on the negatives that's only because the positives are so obvious that there is much to say I'm very much nitpicking here but given the massive popularity of Tailwind I think it's important to provide constructive criticism and to help improve the tool for the entire community on my end Tailwind to stylex has already been upgraded to use Tailwind V4 behind the scenes and I'm excited to take

it even further and more future Rich tailing to Styx by the way probably deserves a video of its own it's a really cool project that lets you take your class names from tailwind and then a compiler because Styx is a compiler rips those out and makes the most optimal set of classes through Styx really really cool stuff and I am more than happy to plug this because this article was great n man is great Styx is great hopefully you all learned something from this one I am hyped to finally get to cover these very real

admittedly small but super valid negatives of tailwind and now that there's a bigger scarier one with V4 it's more important than ever that we're considerate of these things is we use adopt and evangelize the best way to do CSS for most people right now kind of it is what it is I love Tailwind you guys know that stylex is cool hopefully you guys know that Tailwind V4 is great for the most part be careful with the double Stars until next time peace nards