I've been leading a team on a recent project and the hardest part was by far to try and make everyone feel comfortable with "resisting complexity". Copy and paste stuff with multi cursor instead of abstracting components that will inevitably change requirements and scope. Tailwind really shines when you keep everything super simple, as counter-intuitive as this may sound.
For simple sites plain CSS and style HTML attibute is good, for complex sites Bootstrap/semantic css + BEM/SMACSS is good. Tailwind is good for nothing.
So because the PM can’t do their job and nail down a concrete set of requirements, your devs aren’t allowed to do their job and build a concise maintainable system? Doesn’t sound like a winning strat to me but here I was thinking DRY was an important programming principle.
@@0oShwavyo0 in the real world requirements change, not really anyone at fault for that. Also calling DRY an important programming principle is just really funny to me
honestly I think the first tip is not really necessary bc the official tailwind docs have a great search bar! I'm new to tailwind and so the best way I found to learn it is to simply keep open the docs and when I'm trying to do something that I dont remember/know how to do I simply go on the that search bar and type whatever I want with css. e.g. If I type "background-color" immediately pops-up the tab with the bg--color-yyy. I think it is fantastic and I would recommend giving it a try!
Great vid Theo! I definitely feel you when it comes to the order of classes. Whenever I open someone elses codebase and find out the Tailwind classes are all over the place, I die inside a little.
Thank you for opening my mind to tailwind and saving me from css hell. I was able to do with tailwind in one weekend what I was trying to do with css for months now and I had zero tailwind experience before and I am still a noob in tailwind but I consider it an infinitely superior and easier solution.
There are 3 use-cases I've used @apply: 1. consistent styling for link elements across the entire application, changing them in every single file while prototyping was pain and using @apply seemed like the simpler solution than introducing an entire component for it 2. scrollbar styling. There's no element to apply class= to. 3. complex selectors, for example modifying the style of a parent component based on the state of a deeply nested one that may or may not exist in the current component tree. Perhaps this should use something like React context instead, but CSS felt like a more light-weight solution and inline tailwind cannot accomplish it alone.
1. You should make a Link react component and put the styles in there. Use a lib like joe-bell/cva to make it easy to pass props to customize the link's styling via variant names. Links are definitely the kind of situation you should use a component. 2. You can probably just put the styles straight up in your app.css file for scrollbar. Or you could use a plugin like tailwind-scrollbar (third-party) which adds classes to control that. But tbh, I don't see the value is changing the scrollbar, I think it makes more sense to let browsers handle that automatically. 3. Look at the group class. It's not a problem anymore. You can even have named groups for deep nesting since 3.2
@@Ruhigengeist for 2. the point of @apply instead of plain css is to still benefit from and stick to tailwind’s colours and spacing values without replicating them manually. For 3 group is a good call but in my case I was changing the style of the parent based on the nested child’s React state. The :has selector in CSS makes that super easy to do while bubbling up and handling the state would need some amount of code scaffolding
@@3ventic You can still use tailwind colors with theme(colors.blue.500) in SCSS instead of @apply. That's the recommended approach. You can use has in Tailwind too, with a selector like [&:has(p)]:bg-red-500 and you can combine that with groups too. Keep in mind that :has isn't supported in Firefox... still. So that's not a portable thing to use.
@@Ruhigengeist luckily I’m not working with browsers. Pulling in sass as a dependency just to avoid @apply seems wrong. There has selector syntax for tailwind is something I wasn’t aware of. That’s definitely an improvement
The only time i would consider @apply is for text styles. Having 2-3 text styles that i can consistently use across an app helps keep the design clean. I found prettier tailwind sorting because of t3 and i wish i found it earlier! Great stuff!
Yeah, that's probably fine. But you have to be really careful not to overuse it. It's a really fine line to be riding. I rather not use it at all (I ban it from my projects) to not risk getting myself in trouble. The Reusing Styles page in the docs (part near the bottom) does a good job of explaining why it's not a good idea to use it for everything.
@@Ruhigengeist Let's say you have md files in your project and you want consistent styling for h1, h2, p, li ... tags. How do you do it? Do you duplicate the same styles on every md file or is it better to use @apply?
@@unlorde Check out the official tailwind typography plugin. It's specifically designed to be used as a wrapper around Markdown content so you can apply some overrides to elements within.
2:00 if you are using a JS framework like React (rather than just HTML) then just create a constant for your multiple use class, and reference it in your JSX.
For fixing the order of applying classes, I usually use tailwind-merge. It merges classes like clsx(classnames) and removes all conflicts. Like if you had "bg-zinc-800 bg-red-200", it will fix the conflict and it will become just "bg-red-200". Very useful.
I agree it’s hard to convince that use copy paste if it’s making your code simpler, cleaner and easier to understand then use it. You don’t have to literally follow DRY principle. This applies everywhere not just for tailwind ☺️
There's a fine line between WET and DRY code. It's important to remember that DRY isn't always better, because more DRY = more coupling. I feel like there are a 3 types of developers related to this: Those who haven't learned about DRY yet, those who follow it religiously, and those skilled enough to know when and when not to use it.
About @apply, correct me if I am wrong. I find it useful when I build a list of components, when a specific component may have an active state, and for this active state I define a lot of classes. I use Vue, and in the tag I define an .active class, where I @apply these classes, and then provide that class to the active element.
Actually with our team we've found a good way to use the @apply. We are basically creating a custom package for our Vue elements, and instead of using a Button Default vue component for re-using it in the other buttons for the basic construction we just made an button-default class in apply.
Tailwind is a just plain CSS. Your mistake is that you are not using Bootstrap. You unable to understand your mistake because of Dunning-Kruger effect.
@@paemox Bootstrap dictates a lot about how your website looks, and can be a pain to customize. Plain CSS is great for customization, but don't you think tailwind is so much easier and faster?
@@ZantierTasa You must not use all Bootstrap styles, it has many CSS classes that is more powerful and don't have effect on website look. Tailwind kills semantics, Bootstrap + BEM/SMACSS don't kills it.
final tip, nobody cares, unless the client is requesting for you to build the project with a specific library or framework using what your most comfortable with is always the best option, if you don't like tailwind stick with other things.
One of the first really useful "I wish I knew" videos I've seen! I've started out as web-developer, moved to server-side things in the past, but now heard this thing "tailwind" and didn't know how to handle it. Thanks a lot for linking the main developers feeling on things! Just one question I couldn't quite get answered here: In recent years, people are seemingly more and more relaxed about resources, and (being heavy on server-side stuff) I see people building websites just hammering in stuff upon stuff, and writing that much in HTML files feels like just adding more to the bandwidth. It's true, that network connections are getting faster all-over, but this doesn't mean we should be indifferent about it. -> After writing this, I feel dumb ... I'm referring to - let's say 1000 characters, which is a hack lot of classes! - but this still is not much more than 1kb in actual size ...
When I read the recommendation about using multi-cursor editing instead of reusing I was like "you must be kiding" but you convinced me to give it a try
For the multiple child elements with the same classes, using new selectors like "[&>*]:text-blue-700 " would also apply those changes to children, in case you have tens of elements to style and can't make'em components.
@@JEsterCW Agree, I knew the name of it, but wanted to make it clear for the people who haven't heard of it by calling it that, also thought it may sound snobby to just throwing terminologies around which you had no problem with, which is fine.
That's cool if you want to apply a single style, but if you need multiple things applied to those child elements, you have to repeat this selector each time, right? I would argue that using classes directly on the elements makes their styling less coupled to HTML markup and probably more straightforward because you don't have these classes just thrown on the parent with the rest of parent element classes. I do understand if you need some styling to apply to children if you hover over the parent element then it would make sense, but I think I would usually avoid these complex selectors.
One thing that I found strange when starting with tailwind was that I was making less components, and just copy pasting styles and I thought that it wasn't a good practice, I was forcing myself to make more components but I felt it wasn't a great experience when comparing to, say, styled components. With time it just got normal to me, copy pasting is fine with tailwind!
I am still in the beginning stages with tailwind and i feel exactly the same. I even created components which i am probably going to remove again after watching this video 😅
Sveltekit with tailwind is so gooooooooddddd! Feels like writing vanilla html, css, and JavaScript but waaaaaaaaay better. One problem I have with tailwind is documentation. I haven't found a easy to understand way of adding documentation to what you are doing like with vanilla css and comment blocks. I like to add a lot of documentation btw.
amen to prettier! I didn't even think of these tips since they have been a part of my workflow since I picked up tailwind. I can't believe devs don't have these tricks in their back pocket, but hey thanks to you now they do!
confession: I'm still overusing @apply because I was trying to keep my codebase DRY. I should have probably taken the easy path and just copy/paste but I've gone to far. send help :rofl:
okay but what about save the style for a input in a variable and then called that variable in the input field to style it? is a problem of performance this approach? I am student.
I supose you're using a js framework right? That's the idea for components and recommended by TW docs. Make your input a component and style there. (Assuming this input will be used in other places of course).
I was a hater for a bit but finally tried it. It actually re-inspired me to design again. Of course, I HATE all the classes inline like that because after a bit its hard to decipher those lines. Old eyes :D. Overall I have an appreciation for it. I would use it on quite a bit of projects but not all.
I can't believe I've been a CSS dev for 13 years and have now for the first time since then heard a professional bring up the CSS issue of order in the stylesheet trumps class order. It's an issue I am certain all web devs encounter, yet is never talked about. Thank you for finally mentioning this issue
I'll have to think about some of these suggestions really hard. Normally I couldn't agree more with your advice but there's a number of items here you mentioned that I break some of my fundamental development rules. I think one of the biggest things that is probably creating this rift is that in 20 years I have not experienced the problems you're describing to any significant degree. Now I'm wondering what other dev principals that I'm following that have saved me from these issues so I can share them :D I really like @apply and I'm wondering a) what problems people usually run into with it, and b) what the "one of the biggest benefits" that you're talking about was. The consistency provided by the prettier plugin is nice, but I find myself struggling to debug or review items because it moves the media query, hover, etc to the end of the list away from the related items. If they fixed this one item, keeping all related classes together, I'd be much happier with it.
If you're finding the need to use @apply for common text styles or other oft used combinations of classes, consider adding these to your config as a plugin or a theme extension instead. That way you get all the benefits of tailwind and the JIT compiler as if they were native classnames. The only downside is if you need to tweak or add/remove those styles you have to restart the server which should be nbd.
@apply is crucial for reusable components (read companies ui-kit) to make sure that base classes of the components are imported before Tailwind utility classes, so extension and override of the reusable components via Tailwind utility classes is possible and will never have any issues with specificity.
I agree with all of it except the copy paste part. It's never going to work out in large product codebases. Especially when the team is not filled with hyper aware engineers. It's good only until it deviates. Then it will be a massive pain when the design systems changes. Abstracted components will give you easy consistent styling for all teams. Just did a painful migration between design systems and this was one of the biggest pain points
Hi First of all, I love Tailwind and I use it on all of my projects. I have a question for #3: - What technical issues are you talking about? If you're talking about the naming conventions, then there are standards for this (check BEM). Everyone should be aware that using only tailwind classes you are limited with what tailwind has implemented from CSS. But CSS has so many options and I personally wouldn't recommend to anyone to only use classes in HTML, as it makes the code so much cluttered and harder to read and maintain. Not to mention it doesn't comply with the SRP. On the other side, using a separate CSS file, you have full control to all the properties and can choose to use either Tailwind with @apply, either some custom styles or animations. Not to mention the reload performance is better as only CSS is changed. Also, I don't think the costs of supporting @apply is our concern nor should be a decisive factor in how we write code. The tools we use should only improve our productivity.
theo, I love you. I consider myself an experienced developer and someone who really cares about high-level concepts and tries to understand the underlying issues and solutions But still, each of your videos are new gold nuggets to me that I didn’t even think of, OR even worse - something I was thinking about, but couldn’t been able to build a model in my head
I don't quite agree with the recommendation on @apply, it's much easier to change the style of your titles for example in a single file rather than having to search for them in, say, a big project, your 300 jsx files. And no, for a design system, I'd rather change the style of every basic HTML tag than create components, there are a ton of reasons for that. Yes, tailwind makes life easier, but it cannot replace entirely design systems, css...
You know what would be cool? Another wrapper around tailwind with another layer of abstraction which translates into tailwind, which translates into CSS. That would solve ALL problems on the web.
Dude, tailwind + prettier is gonna be so good. I try to follow the order that I see in Tailwond UI but yea, it eventually stars going all over the place. Dope. 🤙🏼🤙🏼🤙🏼
If we should eliminate the use of @apply feature, How can we style CMS contents built using pagebuilder structure since we can't add the classes on it? Example, Magento Pagebuilder feature.
Hi theo, In svelte you can use class:={} As an attribute to an element/component This mixed with the @apply can provide good results that does not hurt the readability or locality of the code, since svelte has a per component styles Which is a good pattern, what do you think ?
from the outside I see quite a lot of benefits to the @apply feature, it reduces having to grep through your components if you ever change the theme of your site and want let's say different kind of container components to share a style. You'd need to either import a constant string with the classNames, or make up your own convention such as a th-container (themed container) class name to share across multiple components. I find myself making a LinkButton (anchor tag) and ActionButton (button tag) component with virtually identical styles in most projects, so a th-button className would help with that. Not that I know what I'm talking about given that I've never used tailwind myself and I'm gonna keep happily using my mix of global stylesheet + cssmodules/scoped styles for components.
The time required to spam ctrl-d isn't the only cost. That kind of repetition also increases the size of your diff. I'm not saying your git history has to be perfect, but it adds noise when doing code review. Not a deal breaker, just something else to consider.
Half agree. That "noise" is also an indicator of "how many places this change effects". If you change a component, you have no idea how many places it is used without opening up an editor
Wait... People have been not using cheat sheets!? Cheat sheets are the best way to shortcut to memory of the big picture so you can zoom in when needed and zoom out when you get lost.
Cheat sheets: Using cheat sheets can help you quickly find the right Tailwind classes and understand the syntax, especially if you're already familiar with CSS. Keeping it simple: Tailwind encourages simplicity. Don't be afraid to copy and paste class names or duplicate styles when it makes sense. It's often the easiest and most maintainable solution. Avoid using @apply: The @apply feature in Tailwind allows you to apply Tailwind classes in traditional CSS classes. However, it's recommended not to use this feature extensively as it can cause technical issues and complicate the codebase. Order of Tailwind classes: The order in which you apply Tailwind classes is important. Using a tool like Tailwind prettier auto-sorting can make it easier to identify conflicting classes and streamline code review. Avoid CSS class order dependencies: In CSS, the order of class names in the HTML doesn't dictate the order of style application. Relying on a consistent class order can help avoid debugging issues related to class order differences. Embrace copy-pasting: Tailwind's consistent class structure makes it easy to copy and paste styles between projects. You don't always need to install or abstract styles as reusable components. Copying and pasting can save time and provide reliable results. Use the Tailwind config wisely: Avoid extensively modifying the Tailwind config file. Instead, use it to add new styles rather than changing existing ones. Trying to make Tailwind work like other CSS frameworks or libraries can lead to unnecessary complexity.
I use the @apply directive to specifically make global styles, say text-style classes that to match a design system, `.ts--h1` or form input resets--there are not all that many things that make the cut.
I don't understand your take on @apply directive. We use Wordpress (php and tailwind) to make websites, and we include a base styling to use on every website (like distance between different sections, text sizing, etc.). So for not repeating everything on every project, we have created a base css file with @apply directives with custom name classes which we can now use in our documents. It's also perfect for using with Gravity form styling and/or wysiwyg editor styling (we use prose in that case). So, I mean, there's the use for it, but I can see why you would want to avoid it in a one time deal project.
I'm using vanilla CSS cause I'm a backend guy. Don't have time to learn framework. But this guy is recruiting me to use Tailwind. I will start tomorrow don't you worry😂
I use @apply, and I like to think my usage is responsible. I need to put a lot of buttons in places that have a lengthy tailwind signature, all the same, and it's so much easier and concise to say my special classname and move on. Is this wrong? It feels so right.
I'd say that it's wrong, yes. The recommended way to do it is to write a button component in your JS framework which handles applying the classes in there. Then it's only in one place in your codebase, and not "far away" from where you're spending all your time, i.e. your components. See the Reusing Styles docs page, the part near the bottom explains well why using @apply is usually a bad idea.
@@Ruhigengeist thanks for the suggestion! I'm using react and you're right, it's not that much of a leap to extend my simple button to its own component. I felt like a new component was excessive whereas a css class was appropriate, but seeing it the other way makes a lot of sense. I'll give it a shot and see how that feels.
I want to use default classes for Button cmp, but I also want to have an option to override this classes with customClassNames prop. What should I do? Currently I'm using "default-btn" class with "@apply" (it has lower specificity, than customClassNames)
i wish tailwind extension had the valid classes underlining like unocss extension, it makes it easier to see if you misspelled or wrongly syntaxed any classes specially when doing arbitrary values
overall I agree... regarding @apply - when you need to apply style to components that you have no control over their html (e.g. external components/plugins, etc...) - @apply is the least worst option especially considering breakpoints and variants handling
repeating the same classnames means repeating the same everything else though in this specific use case at 2:30. That's very non declarative or react-eques to do. For consistency and chrissakes better readability just make a component lol
Thanks for the interesting video. Can you point to some open source React app using tailwind properly, so that people can refer to it and see how it looks in production. It would be specifically interesting to see apps with all kinds of widgets rather then landing page kind of applications.
Personally, I avoid any dependencies that has opinionated styling. Limiting yourself to only headless libraries (tanstack-table, react-hook-form, etc) saves you from having to override things. But yeah, it's not a bad solution if you're truly stuck having to embed opinionated HTML in your app.
@@Ruhigengeist believe you me I would... sometimes I just can't be bothered to code up a fully featured datepicker... I'd use react-aria but their js docs examples, aren't easiest to get running in typescript.
@@SeanCassiere yeah, that's totally fair. A headless date picker is almost impossible because there's so many little bits and bobs involved to making it work. I really wish there was a good way to use JetBrains' Ring UI date picker in a way that didn't require pulling in that whole framework. Because _damn_ that's an amazing date picker - check it out if you haven't seen it.
Debugging conflicting styles is annoying, but it souldn't be too bad? In my experience, inspect element, Chrome shows the css in the reverse order it's being applied (latest applied first), and shows clearly which styles are overridden by something that comes after. It is annoying to deal with for sure, but never found it to be too much of an issue.
Hey Theo, nice lightcurve you got there on your left! How come you have one on your wall? I'd wager its probably a Kepler SC light curve of some object?
The only one I don't do, is use the prettier plugin, and the reason is that I don't use prettier, because I think it's a bad tool. But I do 100% agree that sorting Tailwind classes is the correct thing to do. I just happen to do it by hand. Rant: prettier is bad. It doesn't value human readability at all in how it decides to wrap code. For example, if you have 5 useState one-liners in a row in your component with a simple scalar default (null, [], "", etc) then I expect them to all be one liners. But if the names of the state variable + setter are too long (because they're named descriptively and accurately), then they might cross prettier's line width limit, and wrap the scalar default value for the useState to the next line, and the closing paren to the next line after that. That looks _so fucking ugly_. That is not "pretty", prettier. Fuck you if you think that's pretty. I have many more examples like that which prettier does a shit job, like JS inside heavily nested HTML. I get mad at it so often because it makes my eyes hurt. Also, people have complained about this sort of behaviour for years, but the prettier team is against making these sorts of things configurable, even with hundreds of 👍 on the issues. I'm not aware of any other good formatting tool that doesn't suck regarding line wrapping, so I don't use any in JS. I wish there was one that worked more like gofmt which doesn't care about line length, but more heavily emphasises alignment and readability instead. That would be _amazing_.
I don't use Prettier, but I was willing to go through the trouble of essentially ejecting my formatting settings from VSCode and getting ESlint to play nice. That is until I learned that there's no way to turn off Prettier's code wrap behavior. That's a dealbreaker for me. I'm not exactly sure how I managed it, but all my formatting is handled by ESlint and VSCode, and here I can turn on/off the character limit as I please, while getting `eslint --fix` with import sorting, indent fixes, etc. at the click of a button. I'd be surprised if there's anything that Prettier can do that ESLint can't. I really want the TW class sorting, but it's just not worth it if I have to give up all the good stuff that I have now and get locked into Prettier's BS.
@@unowenwasholo good point. I should probably spend some time looking into turning that stuff on in eslint. It's just not as automatic obviously as something like gofmt which is a bummer.
@@unowenwasholo yeah that's cool for your setup, but what if you work in a team? Everybody is now forced to use VSCode and use your settings, but maybe they don't want to use VSCode. These tools should just be set up outside the editor and not let anyone worry about them anymore. Regarding Prettier formatting, can't you just set printWidth to something like 999 and it will basically never break into new line? I personally like Prettier for formatting because it doesn't get in my way and I can just write code and not have debates with people about code formatting. We just set it up and be done with it. I hate using ESLint for code formatting linting because it shows warnings in my editor when I work in such a codebase. I don't want to get squiggly lines for code formatting problems that don't impact me, I want warnings/errors for actual problems in code.
@@rand0mtv660 Setting a large printWidth will then _unbreak_ lines. You can't tell Prettier to sit down and not touch line breaks, it will force lines to break/unbreak according to its config. I'm not arguing that the TW should have ignored Prettier, just that Prettier is not a viable solution everyone because of its opinionated design and it would be nice if there were other options for TW class sorting in addition to Prettier. I understand that some many people / codebases must allow a suboptimal ESLint config for warnings and the like. I'm fortunate enough to work in ones where I make it a point to address any and all warnings.
If you read his reasoning, @apply is not bad in simple (flat) use cases. The problems start when you start doing inheritance stuff and @applying user classes
Genuine question RE multiple cursors for productivity. What if I want to change every other element but not all of them? Multiple cursor tools typically don’t offer that level of granular control, it’s usually all or nothing, so if you’re relying on them to manage changes in bulk you’d be less likely to want to change styles on some matching elements but not all it would seem.
just select every other element? Or the search & replace functionality in your editor of preference should too be able to do it. If anything, you should be using something like vim if you want this kind of editing out of the box
In VSCode, you can hold Alt and click on things to add another cursor. Or Ctrl+K then Ctrl+D to skip the last one and select the next one. Ctrl+U to remove the last one. Also, if you use Ctrl+D when the cursor is in front of a word (and not selected) it will select only exact matches of that word, skipping substring matches.
@@javierflores09 i use eMacs in evil-mode so not really asking for my workflow specifically, I just didn’t really get the benefit of multiple cursors here unless you need to change every instance of “font-bold” to something else, which could just as easily be done with find & replace. Seems like there are specific shortcuts for skipping matches when adding new cursors, so now it’s making sense to me why you might want to do this.
A reused component wouldn't make this any better. If anything it would make it way worse. The concept of "every other" still has to exist in your code somehow
I agree with everything except the @apply rule. I can imagine it's difficult for tailwind to work around... I imagine it's pretty complicated to integrate with a bunch of different bundlers and environments, but using it for something containing some sort of global theme to a class that needs some css that tailwind can't handle is awesome in some cases. That rarely happens, but right now I'm working on something with some Shadcn (of course it's Shadcn) and being able to change the shadCn defined variables in one location and have it effect the tailwind config and the internal classes at the same time is a life saver. In a pretty large and fairly complicated app I used that in maybe 2 places, but it add's so much predictability that I can change one css file and not worry about forgetting something... especially when Next's dev server is so sh-t and my M1 macbook can literally barely load this massive app in development to check how things look, and it definitely can't navigate between more than one or two pages before needing to restart.
After trying tailwind myself, I think it's fine to components that you only style once, but on multiple components I'd rather make css classes It's something that adds to css, not replacing it
If you have a class repeated 10 times, you can easily change it simultaneously in all places, but then you run into issues when you want to play with styles in dev tools.
I've been leading a team on a recent project and the hardest part was by far to try and make everyone feel comfortable with "resisting complexity". Copy and paste stuff with multi cursor instead of abstracting components that will inevitably change requirements and scope. Tailwind really shines when you keep everything super simple, as counter-intuitive as this may sound.
For simple sites plain CSS and style HTML attibute is good, for complex sites Bootstrap/semantic css + BEM/SMACSS is good. Tailwind is good for nothing.
So because the PM can’t do their job and nail down a concrete set of requirements, your devs aren’t allowed to do their job and build a concise maintainable system? Doesn’t sound like a winning strat to me but here I was thinking DRY was an important programming principle.
how to join your team 😁
@@davidomar742 so because it’s not turing complete we should be verbose and redundant now?
@@0oShwavyo0 in the real world requirements change, not really anyone at fault for that. Also calling DRY an important programming principle is just really funny to me
You truly realise the benefits of Tailwind when you work on a project that does not include it.
honestly I think the first tip is not really necessary bc the official tailwind docs have a great search bar! I'm new to tailwind and so the best way I found to learn it is to simply keep open the docs and when I'm trying to do something that I dont remember/know how to do I simply go on the that search bar and type whatever I want with css. e.g. If I type "background-color" immediately pops-up the tab with the bg--color-yyy. I think it is fantastic and I would recommend giving it a try!
Totally agree
Yeah, scrolling up and down a cheat sheet is way slower than me just hitting cmd + k and typing the css property in the website's search.
@@JoRyGu for me too!
Great vid Theo! I definitely feel you when it comes to the order of classes. Whenever I open someone elses codebase and find out the Tailwind classes are all over the place, I die inside a little.
There is a eslint rule that takes care about the order of class names
The whole series about tailwind by its creator is well worth a watch on TH-cam
Thank you for opening my mind to tailwind and saving me from css hell. I was able to do with tailwind in one weekend what I was trying to do with css for months now and I had zero tailwind experience before and I am still a noob in tailwind but I consider it an infinitely superior and easier solution.
There are 3 use-cases I've used @apply:
1. consistent styling for link elements across the entire application, changing them in every single file while prototyping was pain and using @apply seemed like the simpler solution than introducing an entire component for it
2. scrollbar styling. There's no element to apply class= to.
3. complex selectors, for example modifying the style of a parent component based on the state of a deeply nested one that may or may not exist in the current component tree. Perhaps this should use something like React context instead, but CSS felt like a more light-weight solution and inline tailwind cannot accomplish it alone.
1. You should make a Link react component and put the styles in there. Use a lib like joe-bell/cva to make it easy to pass props to customize the link's styling via variant names. Links are definitely the kind of situation you should use a component.
2. You can probably just put the styles straight up in your app.css file for scrollbar. Or you could use a plugin like tailwind-scrollbar (third-party) which adds classes to control that. But tbh, I don't see the value is changing the scrollbar, I think it makes more sense to let browsers handle that automatically.
3. Look at the group class. It's not a problem anymore. You can even have named groups for deep nesting since 3.2
I’m okay with all of these
@@Ruhigengeist for 2. the point of @apply instead of plain css is to still benefit from and stick to tailwind’s colours and spacing values without replicating them manually. For 3 group is a good call but in my case I was changing the style of the parent based on the nested child’s React state. The :has selector in CSS makes that super easy to do while bubbling up and handling the state would need some amount of code scaffolding
@@3ventic You can still use tailwind colors with theme(colors.blue.500) in SCSS instead of @apply. That's the recommended approach.
You can use has in Tailwind too, with a selector like [&:has(p)]:bg-red-500 and you can combine that with groups too. Keep in mind that :has isn't supported in Firefox... still. So that's not a portable thing to use.
@@Ruhigengeist luckily I’m not working with browsers. Pulling in sass as a dependency just to avoid @apply seems wrong. There has selector syntax for tailwind is something I wasn’t aware of. That’s definitely an improvement
The @apply directive is really useful for styling HTML content you don't control (i.e. coming form a CMS).
This is actually a very good point
MUI sx prop is better
@@alesholman801 I don't see how that could help styling content from a CMS.
@@runonce I was just talking about the content you don't control
@@alesholman801 Still don't follow, please elaborate.
The only time i would consider @apply is for text styles. Having 2-3 text styles that i can consistently use across an app helps keep the design clean. I found prettier tailwind sorting because of t3 and i wish i found it earlier! Great stuff!
Yeah, that's probably fine. But you have to be really careful not to overuse it. It's a really fine line to be riding. I rather not use it at all (I ban it from my projects) to not risk getting myself in trouble. The Reusing Styles page in the docs (part near the bottom) does a good job of explaining why it's not a good idea to use it for everything.
@@Ruhigengeist Let's say you have md files in your project and you want consistent styling for h1, h2, p, li ... tags. How do you do it? Do you duplicate the same styles on every md file or is it better to use @apply?
@@unlorde Check out the official tailwind typography plugin. It's specifically designed to be used as a wrapper around Markdown content so you can apply some overrides to elements within.
just use CVA to abstract text styling and add it as a component in your project. Thank me later
I only use @apply on a wordpress frontend where there is a lot of legacy classes already in the HTML coming from wordpress that we cannot update.
2:00 if you are using a JS framework like React (rather than just HTML) then just create a constant for your multiple use class, and reference it in your JSX.
For fixing the order of applying classes, I usually use tailwind-merge. It merges classes like clsx(classnames) and removes all conflicts. Like if you had "bg-zinc-800 bg-red-200", it will fix the conflict and it will become just "bg-red-200". Very useful.
I agree it’s hard to convince that use copy paste if it’s making your code simpler, cleaner and easier to understand then use it. You don’t have to literally follow DRY principle. This applies everywhere not just for tailwind ☺️
There's a fine line between WET and DRY code. It's important to remember that DRY isn't always better, because more DRY = more coupling.
I feel like there are a 3 types of developers related to this: Those who haven't learned about DRY yet, those who follow it religiously, and those skilled enough to know when and when not to use it.
About @apply, correct me if I am wrong. I find it useful when I build a list of components, when a specific component may have an active state, and for this active state I define a lot of classes. I use Vue, and in the tag I define an .active class, where I @apply these classes, and then provide that class to the active element.
Actually with our team we've found a good way to use the @apply. We are basically creating a custom package for our Vue elements, and instead of using a Button Default vue component for re-using it in the other buttons for the basic construction we just made an button-default class in apply.
So after almost 2 years of using Tailwind I can say confidently; I do no mistake 🤘😂
Tailwind is a just plain CSS. Your mistake is that you are not using Bootstrap. You unable to understand your mistake because of Dunning-Kruger effect.
@@paemox 🤡
@@paemox Bootstrap dictates a lot about how your website looks, and can be a pain to customize. Plain CSS is great for customization, but don't you think tailwind is so much easier and faster?
@@ZantierTasa You must not use all Bootstrap styles, it has many CSS classes that is more powerful and don't have effect on website look. Tailwind kills semantics, Bootstrap + BEM/SMACSS don't kills it.
Website look CSS classes in HTML tags (Tailwind CSS) is a crapware.
final tip, nobody cares, unless the client is requesting for you to build the project with a specific library or framework using what your most comfortable with is always the best option, if you don't like tailwind stick with other things.
Other people on your team care
Found the redux dev
@@colinbtw8720 i prefer zustand and jotai
@@anonanon7368 if your working in a team setting then the team leader would choose the stack.
people have different preferences
This is just general app development advice. Theos clearly talking about tips to improve using tailwind
One of the first really useful "I wish I knew" videos I've seen! I've started out as web-developer, moved to server-side things in the past, but now heard this thing "tailwind" and didn't know how to handle it. Thanks a lot for linking the main developers feeling on things!
Just one question I couldn't quite get answered here: In recent years, people are seemingly more and more relaxed about resources, and (being heavy on server-side stuff) I see people building websites just hammering in stuff upon stuff, and writing that much in HTML files feels like just adding more to the bandwidth. It's true, that network connections are getting faster all-over, but this doesn't mean we should be indifferent about it.
-> After writing this, I feel dumb ... I'm referring to - let's say 1000 characters, which is a hack lot of classes! - but this still is not much more than 1kb in actual size ...
2:38 or you just add one 'font-medium' to the nav element...
Thank you, you covered some topics I was wondering about.
Just started using Tailwind. This is super helpful. Thank you!
the prettier plugin tip is pure gold, thank you so much, i really didn't know it existed
When I read the recommendation about using multi-cursor editing instead of reusing I was like "you must be kiding" but you convinced me to give it a try
For the multiple child elements with the same classes, using new selectors like "[&>*]:text-blue-700 " would also apply those changes to children, in case you have tens of elements to style and can't make'em components.
@@JEsterCW Agree, I knew the name of it, but wanted to make it clear for the people who haven't heard of it by calling it that, also thought it may sound snobby to just throwing terminologies around which you had no problem with, which is fine.
That's cool if you want to apply a single style, but if you need multiple things applied to those child elements, you have to repeat this selector each time, right? I would argue that using classes directly on the elements makes their styling less coupled to HTML markup and probably more straightforward because you don't have these classes just thrown on the parent with the rest of parent element classes.
I do understand if you need some styling to apply to children if you hover over the parent element then it would make sense, but I think I would usually avoid these complex selectors.
I massively appreciate your channel and have learned so much from you - thank you. Congrats on hitting 100k
Tailwind is simple but powerful.
One thing that I found strange when starting with tailwind was that I was making less components, and just copy pasting styles and I thought that it wasn't a good practice, I was forcing myself to make more components but I felt it wasn't a great experience when comparing to, say, styled components. With time it just got normal to me, copy pasting is fine with tailwind!
I am still in the beginning stages with tailwind and i feel exactly the same. I even created components which i am probably going to remove again after watching this video 😅
Sveltekit with tailwind is so gooooooooddddd! Feels like writing vanilla html, css, and JavaScript but waaaaaaaaay better. One problem I have with tailwind is documentation. I haven't found a easy to understand way of adding documentation to what you are doing like with vanilla css and comment blocks. I like to add a lot of documentation btw.
I first tried Tailwind when that prettier plugin wasn't s thing yet and it was driving me mad.
It's soooo much better having that.
Yes, 100% 😉
I love this type of video [short, concise, informative, impactful] in general and this specific video in particular - THANK YOU!
amen to prettier! I didn't even think of these tips since they have been a part of my workflow since I picked up tailwind. I can't believe devs don't have these tricks in their back pocket, but hey thanks to you now they do!
Shoutout to you for telling me about the Prettier plugin. That is gonna save me so much time.
confession: I'm still overusing @apply because I was trying to keep my codebase DRY. I should have probably taken the easy path and just copy/paste but I've gone to far. send help :rofl:
okay but what about save the style for a input in a variable and then called that variable in the input field to style it? is a problem of performance this approach? I am student.
I supose you're using a js framework right? That's the idea for components and recommended by TW docs. Make your input a component and style there. (Assuming this input will be used in other places of course).
I was a hater for a bit but finally tried it. It actually re-inspired me to design again. Of course, I HATE all the classes inline like that because after a bit its hard to decipher those lines. Old eyes :D. Overall I have an appreciation for it. I would use it on quite a bit of projects but not all.
Using something like daisyUI with it, makes it even better.
I can't believe I've been a CSS dev for 13 years and have now for the first time since then heard a professional bring up the CSS issue of order in the stylesheet trumps class order. It's an issue I am certain all web devs encounter, yet is never talked about. Thank you for finally mentioning this issue
Excellent. Well delivered to camera. Glad you went crazy with Helen.
I'll have to think about some of these suggestions really hard. Normally I couldn't agree more with your advice but there's a number of items here you mentioned that I break some of my fundamental development rules. I think one of the biggest things that is probably creating this rift is that in 20 years I have not experienced the problems you're describing to any significant degree. Now I'm wondering what other dev principals that I'm following that have saved me from these issues so I can share them :D
I really like @apply and I'm wondering a) what problems people usually run into with it, and b) what the "one of the biggest benefits" that you're talking about was.
The consistency provided by the prettier plugin is nice, but I find myself struggling to debug or review items because it moves the media query, hover, etc to the end of the list away from the related items. If they fixed this one item, keeping all related classes together, I'd be much happier with it.
That prettier tip was awesome. Can't wait to play with it
You’ve helped me so much on my full stack journey. I love these videos when you don’t seem cranky by others stupidity 😂😂
If you're finding the need to use @apply for common text styles or other oft used combinations of classes, consider adding these to your config as a plugin or a theme extension instead. That way you get all the benefits of tailwind and the JIT compiler as if they were native classnames. The only downside is if you need to tweak or add/remove those styles you have to restart the server which should be nbd.
@apply is crucial for reusable components (read companies ui-kit) to make sure that base classes of the components are imported before Tailwind utility classes, so extension and override of the reusable components via Tailwind utility classes is possible and will never have any issues with specificity.
"...it will keep you from having miserable nightmares in the future" Spoken with the voice of experience 🤣
agree
i love tailwind eslint, like a code completion to turn px-2 and py-2 into p-2 in case i dont on accident
I agree with all of it except the copy paste part. It's never going to work out in large product codebases. Especially when the team is not filled with hyper aware engineers.
It's good only until it deviates. Then it will be a massive pain when the design systems changes. Abstracted components will give you easy consistent styling for all teams.
Just did a painful migration between design systems and this was one of the biggest pain points
Hi
First of all, I love Tailwind and I use it on all of my projects.
I have a question for #3:
- What technical issues are you talking about?
If you're talking about the naming conventions, then there are standards for this (check BEM).
Everyone should be aware that using only tailwind classes you are limited with what tailwind has implemented from CSS. But CSS has so many options and I personally wouldn't recommend to anyone to only use classes in HTML, as it makes the code so much cluttered and harder to read and maintain. Not to mention it doesn't comply with the SRP.
On the other side, using a separate CSS file, you have full control to all the properties and can choose to use either Tailwind with @apply, either some custom styles or animations. Not to mention the reload performance is better as only CSS is changed.
Also, I don't think the costs of supporting @apply is our concern nor should be a decisive factor in how we write code. The tools we use should only improve our productivity.
Tailwind state of mind is a real thing
theo, I love you.
I consider myself an experienced developer and someone who really cares about high-level concepts and tries to understand the underlying issues and solutions
But still, each of your videos are new gold nuggets to me that I didn’t even think of, OR even worse - something I was thinking about, but couldn’t been able to build a model in my head
Theo in this video reminds me so much of Richard from Silicon Valley. I love it.
that painting is stunning
Yeah for real man. You totally right about it, it is a tool that has being helping me for quite a while now. Thank you
I love this philosophy for front end development... Keep it simple! Minimize unnecessary abstractions!
This is brilliant and can be applied to so much more than just Tailwind.
This was excellent. Thanks so much, I had no idea about any of this, and I use tailwind all the time.
I don't quite agree with the recommendation on @apply, it's much easier to change the style of your titles for example in a single file rather than having to search for them in, say, a big project, your 300 jsx files. And no, for a design system, I'd rather change the style of every basic HTML tag than create components, there are a ton of reasons for that.
Yes, tailwind makes life easier, but it cannot replace entirely design systems, css...
I don't have Prettier plugin for Tailwind but Prettier seems to update the order on its own. Guess that was integrated after this video?
You know what would be cool? Another wrapper around tailwind with another layer of abstraction which translates into tailwind, which translates into CSS. That would solve ALL problems on the web.
Dude, tailwind + prettier is gonna be so good. I try to follow the order that I see in Tailwond UI but yea, it eventually stars going all over the place. Dope. 🤙🏼🤙🏼🤙🏼
I've used @apply exactly once: Adding some content through a CMS and realistically being unable to edit the classes
If we should eliminate the use of @apply feature, How can we style CMS contents built using pagebuilder structure since we can't add the classes on it? Example, Magento Pagebuilder feature.
Hi theo,
In svelte you can use
class:={}
As an attribute to an element/component
This mixed with the @apply can provide good results that does not hurt the readability or locality of the code, since svelte has a per component styles
Which is a good pattern, what do you think ?
from the outside I see quite a lot of benefits to the @apply feature, it reduces having to grep through your components if you ever change the theme of your site and want let's say different kind of container components to share a style. You'd need to either import a constant string with the classNames, or make up your own convention such as a th-container (themed container) class name to share across multiple components. I find myself making a LinkButton (anchor tag) and ActionButton (button tag) component with virtually identical styles in most projects, so a th-button className would help with that. Not that I know what I'm talking about given that I've never used tailwind myself and I'm gonna keep happily using my mix of global stylesheet + cssmodules/scoped styles for components.
The time required to spam ctrl-d isn't the only cost. That kind of repetition also increases the size of your diff. I'm not saying your git history has to be perfect, but it adds noise when doing code review. Not a deal breaker, just something else to consider.
Half agree. That "noise" is also an indicator of "how many places this change effects". If you change a component, you have no idea how many places it is used without opening up an editor
Good point. Trade offs, like everything in engineering
Wait... People have been not using cheat sheets!? Cheat sheets are the best way to shortcut to memory of the big picture so you can zoom in when needed and zoom out when you get lost.
Cheat sheets: Using cheat sheets can help you quickly find the right Tailwind classes and understand the syntax, especially if you're already familiar with CSS.
Keeping it simple: Tailwind encourages simplicity. Don't be afraid to copy and paste class names or duplicate styles when it makes sense. It's often the easiest and most maintainable solution.
Avoid using @apply: The @apply feature in Tailwind allows you to apply Tailwind classes in traditional CSS classes. However, it's recommended not to use this feature extensively as it can cause technical issues and complicate the codebase.
Order of Tailwind classes: The order in which you apply Tailwind classes is important. Using a tool like Tailwind prettier auto-sorting can make it easier to identify conflicting classes and streamline code review.
Avoid CSS class order dependencies: In CSS, the order of class names in the HTML doesn't dictate the order of style application. Relying on a consistent class order can help avoid debugging issues related to class order differences.
Embrace copy-pasting: Tailwind's consistent class structure makes it easy to copy and paste styles between projects. You don't always need to install or abstract styles as reusable components. Copying and pasting can save time and provide reliable results.
Use the Tailwind config wisely: Avoid extensively modifying the Tailwind config file. Instead, use it to add new styles rather than changing existing ones. Trying to make Tailwind work like other CSS frameworks or libraries can lead to unnecessary complexity.
mvp comment! thanks, bro
Theo,i love backend but you make me accept front end, great video i didnt even know prettier tailwind intergration existed
I use the @apply directive to specifically make global styles, say text-style classes that to match a design system, `.ts--h1` or form input resets--there are not all that many things that make the cut.
I find prettier for tailwind always complains about closing tags for semantic tags - then again I may not have configured it right...?
I dont think I can go back to css. Tailwind just makes blasting stuff out a dream. Super quick, super simple, and the results speak for themselves....
Yes, 100% 😉
I don't understand your take on @apply directive. We use Wordpress (php and tailwind) to make websites, and we include a base styling to use on every website (like distance between different sections, text sizing, etc.). So for not repeating everything on every project, we have created a base css file with @apply directives with custom name classes which we can now use in our documents. It's also perfect for using with Gravity form styling and/or wysiwyg editor styling (we use prose in that case). So, I mean, there's the use for it, but I can see why you would want to avoid it in a one time deal project.
I'm using vanilla CSS cause I'm a backend guy. Don't have time to learn framework. But this guy is recruiting me to use Tailwind. I will start tomorrow don't you worry😂
I use @apply, and I like to think my usage is responsible. I need to put a lot of buttons in places that have a lengthy tailwind signature, all the same, and it's so much easier and concise to say my special classname and move on. Is this wrong? It feels so right.
I'd say that it's wrong, yes. The recommended way to do it is to write a button component in your JS framework which handles applying the classes in there. Then it's only in one place in your codebase, and not "far away" from where you're spending all your time, i.e. your components.
See the Reusing Styles docs page, the part near the bottom explains well why using @apply is usually a bad idea.
@@Ruhigengeist thanks for the suggestion! I'm using react and you're right, it's not that much of a leap to extend my simple button to its own component.
I felt like a new component was excessive whereas a css class was appropriate, but seeing it the other way makes a lot of sense. I'll give it a shot and see how that feels.
I use Ctrl+Shift+L a lot, it's the same as Ctrl+D, but it selects every instance at once
I want to use default classes for Button cmp, but I also want to have an option to override this classes with customClassNames prop. What should I do? Currently I'm using "default-btn" class with "@apply" (it has lower specificity, than customClassNames)
Addiitional tip on #2: use * on parent and it applies on the children.
example:
*:block *:p-2
I've been programming for 11 years and just learned that Ctrl+D will multi-select the next occurrence of what's selected in VS code hahahaha
This vid was genuinely helpful. I wish there was a way to get the prettier-tailwind plugin on neovim
The whole purpose of tailwind is avoiding naming things
i wish tailwind extension had the valid classes underlining like unocss extension, it makes it easier to see if you misspelled or wrongly syntaxed any classes specially when doing arbitrary values
Why not just use unocss though? Do you have any reason to prefer tailwind? I myself use unocss and never wanted to return to tailwind even once yet.
@@twothreeoneoneseventwoonefour5 I do use unocss personaly.
But most teams use use tailwind
eslint-plugin-tailwindcss can warn you about custom classnames which are not related to your Tailwind CSS config 🎉
OMG the prettier plugin! Thanks
Strange thing is, i had never used TW cheat sheet until i'm already very comfortable with the library, all i need was tailwind intellisense
overall I agree... regarding @apply - when you need to apply style to components that you have no control over their html (e.g. external components/plugins, etc...) - @apply is the least worst option especially considering breakpoints and variants handling
I have a client that insisted on redefining REM to be 10px and then making each step in the tailwind sizing be 0.5 rem. So instead of 4px, it's 5px...
repeating the same classnames means repeating the same everything else though in this specific use case at 2:30. That's very non declarative or react-eques to do. For consistency and chrissakes better readability just make a component lol
that css file order sucks, ive spent hours debugging that but yeah now i know where to look.
Thanks for the interesting video. Can you point to some open source React app using tailwind properly, so that people can refer to it and see how it looks in production. It would be specifically interesting to see apps with all kinds of widgets rather then landing page kind of applications.
having links will be great, mate
good tips. Thank you.
Personally, the only reason I use the @apply directive is to override certain third-component styles by targeting their individual classnames.
Personally, I avoid any dependencies that has opinionated styling. Limiting yourself to only headless libraries (tanstack-table, react-hook-form, etc) saves you from having to override things.
But yeah, it's not a bad solution if you're truly stuck having to embed opinionated HTML in your app.
@@Ruhigengeist believe you me I would... sometimes I just can't be bothered to code up a fully featured datepicker... I'd use react-aria but their js docs examples, aren't easiest to get running in typescript.
Currently using Router (beta 68), Table, and Query from the Tanstack in my current project.
@@SeanCassiere yeah, that's totally fair. A headless date picker is almost impossible because there's so many little bits and bobs involved to making it work. I really wish there was a good way to use JetBrains' Ring UI date picker in a way that didn't require pulling in that whole framework. Because _damn_ that's an amazing date picker - check it out if you haven't seen it.
Tailwind really made writing styles faster, now Im ended with writing tailwind in css in vscode without tailwind installed
Debugging conflicting styles is annoying, but it souldn't be too bad?
In my experience, inspect element, Chrome shows the css in the reverse order it's being applied (latest applied first), and shows clearly which styles are overridden by something that comes after.
It is annoying to deal with for sure, but never found it to be too much of an issue.
The automatic class sorter still doesn't work with PHP :(
KUDOS AWESOME SHORT VIDEO!
Hate streaming 10 hours chattering, sorry
Hey Theo, nice lightcurve you got there on your left! How come you have one on your wall? I'd wager its probably a Kepler SC light curve of some object?
The only one I don't do, is use the prettier plugin, and the reason is that I don't use prettier, because I think it's a bad tool. But I do 100% agree that sorting Tailwind classes is the correct thing to do. I just happen to do it by hand.
Rant: prettier is bad. It doesn't value human readability at all in how it decides to wrap code. For example, if you have 5 useState one-liners in a row in your component with a simple scalar default (null, [], "", etc) then I expect them to all be one liners. But if the names of the state variable + setter are too long (because they're named descriptively and accurately), then they might cross prettier's line width limit, and wrap the scalar default value for the useState to the next line, and the closing paren to the next line after that. That looks _so fucking ugly_. That is not "pretty", prettier. Fuck you if you think that's pretty.
I have many more examples like that which prettier does a shit job, like JS inside heavily nested HTML. I get mad at it so often because it makes my eyes hurt. Also, people have complained about this sort of behaviour for years, but the prettier team is against making these sorts of things configurable, even with hundreds of 👍 on the issues. I'm not aware of any other good formatting tool that doesn't suck regarding line wrapping, so I don't use any in JS. I wish there was one that worked more like gofmt which doesn't care about line length, but more heavily emphasises alignment and readability instead. That would be _amazing_.
I don't use Prettier, but I was willing to go through the trouble of essentially ejecting my formatting settings from VSCode and getting ESlint to play nice. That is until I learned that there's no way to turn off Prettier's code wrap behavior. That's a dealbreaker for me. I'm not exactly sure how I managed it, but all my formatting is handled by ESlint and VSCode, and here I can turn on/off the character limit as I please, while getting `eslint --fix` with import sorting, indent fixes, etc. at the click of a button. I'd be surprised if there's anything that Prettier can do that ESLint can't.
I really want the TW class sorting, but it's just not worth it if I have to give up all the good stuff that I have now and get locked into Prettier's BS.
@@unowenwasholo good point. I should probably spend some time looking into turning that stuff on in eslint. It's just not as automatic obviously as something like gofmt which is a bummer.
@@unowenwasholo yeah that's cool for your setup, but what if you work in a team? Everybody is now forced to use VSCode and use your settings, but maybe they don't want to use VSCode. These tools should just be set up outside the editor and not let anyone worry about them anymore.
Regarding Prettier formatting, can't you just set printWidth to something like 999 and it will basically never break into new line? I personally like Prettier for formatting because it doesn't get in my way and I can just write code and not have debates with people about code formatting. We just set it up and be done with it. I hate using ESLint for code formatting linting because it shows warnings in my editor when I work in such a codebase. I don't want to get squiggly lines for code formatting problems that don't impact me, I want warnings/errors for actual problems in code.
@@rand0mtv660 Setting a large printWidth will then _unbreak_ lines. You can't tell Prettier to sit down and not touch line breaks, it will force lines to break/unbreak according to its config.
I'm not arguing that the TW should have ignored Prettier, just that Prettier is not a viable solution everyone because of its opinionated design and it would be nice if there were other options for TW class sorting in addition to Prettier.
I understand that some many people / codebases must allow a suboptimal ESLint config for warnings and the like. I'm fortunate enough to work in ones where I make it a point to address any and all warnings.
If you read his reasoning, @apply is not bad in simple (flat) use cases. The problems start when you start doing inheritance stuff and @applying user classes
See the section at the end of the Reusing Styles docs page. It covers why using @apply is bad. You're throwing away many of Tailwind's key benefits.
Genuine question RE multiple cursors for productivity. What if I want to change every other element but not all of them? Multiple cursor tools typically don’t offer that level of granular control, it’s usually all or nothing, so if you’re relying on them to manage changes in bulk you’d be less likely to want to change styles on some matching elements but not all it would seem.
just select every other element? Or the search & replace functionality in your editor of preference should too be able to do it. If anything, you should be using something like vim if you want this kind of editing out of the box
In VSCode, you can hold Alt and click on things to add another cursor. Or Ctrl+K then Ctrl+D to skip the last one and select the next one. Ctrl+U to remove the last one. Also, if you use Ctrl+D when the cursor is in front of a word (and not selected) it will select only exact matches of that word, skipping substring matches.
@@Ruhigengeist ahh that’s neat I didn’t know about those other multi-cursor shortcuts, thanks for the tip.
@@javierflores09 i use eMacs in evil-mode so not really asking for my workflow specifically, I just didn’t really get the benefit of multiple cursors here unless you need to change every instance of “font-bold” to something else, which could just as easily be done with find & replace. Seems like there are specific shortcuts for skipping matches when adding new cursors, so now it’s making sense to me why you might want to do this.
A reused component wouldn't make this any better. If anything it would make it way worse. The concept of "every other" still has to exist in your code somehow
I agree with everything except the @apply rule. I can imagine it's difficult for tailwind to work around... I imagine it's pretty complicated to integrate with a bunch of different bundlers and environments, but using it for something containing some sort of global theme to a class that needs some css that tailwind can't handle is awesome in some cases. That rarely happens, but right now I'm working on something with some Shadcn (of course it's Shadcn) and being able to change the shadCn defined variables in one location and have it effect the tailwind config and the internal classes at the same time is a life saver. In a pretty large and fairly complicated app I used that in maybe 2 places, but it add's so much predictability that I can change one css file and not worry about forgetting something... especially when Next's dev server is so sh-t and my M1 macbook can literally barely load this massive app in development to check how things look, and it definitely can't navigate between more than one or two pages before needing to restart.
After trying tailwind myself, I think it's fine to components that you only style once, but on multiple components I'd rather make css classes
It's something that adds to css, not replacing it
If you have a class repeated 10 times, you can easily change it simultaneously in all places, but then you run into issues when you want to play with styles in dev tools.
Ideally you should have HMR set up so you can edit your styles in your editor and save, styles should immediately reload in your browser.
This video is basically "teaching everyone DRY too much was a mistake"