10 Tailwind Classes I Wish I Knew Earlier 

True hero

the Web dev simplified we deserve

Great Job!

Nice!

Thank you. I appreciate the video and knowledge it shares but really hate such cheap tricks to mark timestamps as 1,2,3.. so that we are forced to watch the whole video. It makes it really difficult to reference it.

Sounds so much more efficient than using margin-block. What do you do with the all the time you’ve saved

Definitely going to have to try these out ..!

Yeah spacex is good company

i think they defeat the purpose, now you gonna have to know what each utility is instead of just understading what the class directly maps to in css. Also dont space your stuff manually, do create containers that flow to be the design you want.

😮 why

Why would you combine these two? Doesn't make sense to me really.

the selector is easy to remember, the name is following the property and the value, use function and directives, then your code is much more readable, better than using preprocessor

so you don't have to remember anything while using pure css? lmao

Why tho? Why would someone use inline styles when tailwind is available. The only reason to do this is if there's a new CSS property and tailwind don't have support for it yet.

I believe if you are using a state (which is typed string or number) as the direct value then you will most likely use inline. Because tailwind pre compiles it classes, it doesn’t know what num1 is `w-[${num1}px]` state num1 could be anything

Interesting. So tailwind is more about auto completion? I assumed it's about abstracting styles, or it's like shorthand. From what I get, you use it to standardize sizes, and then, for consistency, you also use it for styling something as inline block? The answer I expected to hear is, when I style something to be sticky then I use inline styling. I also thought CSS is pretty good at changing widths of elements based off of what class or attributes they have. I haven't written CSS at any significant scale.

That's really cool. I haven't seen his video, but it is funny we released videos so close together.

In docs, theres page about optimizing for production, you can check it

Try adding tailwind config file in your root folder even just empty one should do the trick

CSS also has line clamp

@@DeepTitanic ye i use css for line clamp but didn't know line clamp in tailwind

Did you read doc? ;)

its not that deep lol

Why not tho

speak for yourself

Just keep it up. I love it

What the problem at all?

Tailwind and Bootstrap are pretty similar

Sorry if I'm out of place, but have you considered hand written CSS? I've only tried hand written and I feel overwhelmed when I look at Tailwind or bootstrap

Tailwind makes very little sense when used in a traditional html page, but thats because Tailwind is essentially inline styling with better dev-ex surrounding it. The cascading part of css can cause issues and unnecessary mental gymnastics when dealing with components, however, so Tailwind fills that niche. It's a specific tool for a specific use case rather than another "use me and only me" bootstrap-type style framework.

@developersteve1658 I would argue that using inline styling and no cascading takes us back to the days before CSS existed. Maybe remembering what that was like makes me biased though. I don't think it's worth the trade off. I can see how its useful for prototyping but right now I wouldn't even entertain the idea of using it in a large project.

@zebraforceone Oh, I get that for sure. With Next.js, Prisma, htmx, etc. It certainly feels like the "old" ways of doing things are coming back and being touted as new, fancy, and revolutionary. When in reality, they're just doing the same thing as .NET, any ORM, or php, respectively. In the case of Tailwind, it's just inline CSS, as you said. It's a step backward, right? However, I don't think it's so black and white. As an industry, web development has put all their eggs into the Javascript basket. With the creation of component-based architecture, we saw the rise of SPAs and the microservice, edge, and cloud architectures as well. All of this time and effort has been spent on making that work, but when we stepped away from those other technologies, I think we lost something. When all you have is a hammer, everything looks like a nail, right? So I see these "new" technologies such as Next, htmx, or even Tailwind as a remaking of tools lost in the shift to the "modern" design principles. Remade in (most importantly) the Javascript component ecosystem. When it comes to styling, components really don't behave well with a fully-opinionated style library that enforces structure like Bootstrap because it breaks component architecture, SASS is the same way, because it is designed around giving you utilities to quickly create classes that traverse the tree and apply styling. CSS, at its core, was created to cascade styling (duh) based on the structure of the DOM. Unfortunately, that behavior is just not suited to components when you are swapping out the DOM all the time. Either you design your components and styling in a way that expects certain DOM elements in certain orders (which is not really maintainable without considerable effort and documentation), or you don't use DOM selectors in your CSS which completely defeats the purpose of CSS in the first place. To get around these problems, we got styled components for a while, which was a hot mess, and I'm sure some other novel solutions, but eventually we got Tailwind. Now, it may seem like Tailwind is inline styling and will bring with it the same problems. However, it's not for one key difference: classes. Tailwind uses classes instead of styles directly, so everything can be changed and configured at the project level. You get the benefit of reusable code and all that without the structural lock-in of DOM selectors or larger classes, all written with and configured in the same language as your components and your business logic, and your database, etc. Tl;dr: I believe Tailwind, amongst other "new" tools in modern web-dev, are coming about because we lost something in recent years. By implementing older tools in modern ways, we are granted the benefit of less mental gymnastics and a better workflow when creating a majority of apps. Newer doesn't always mean better.

"When all you have is a hammer, everything looks like a nail, right?" Yes, not being used to engaged in some mental effort and getting comfortable with the "Computed" panel is, respectfully, in my opinion why people praise the Tailwind hammer :P "Unfortunately, that behavior is just not suited to components when you are swapping out the DOM all the time." Again I'm sorry but I disagree. The approach my team usually takes is to give each component a unique classname or data attribute, usually matching the components classname, then we use SCSS / SASS to wrap all the styling for that component in a single file, which we import from the components JS file. I've done this in dozens of projects now and you can move things around to your hearts content. I appreciate the case for styling components in an isolated way but the flip side of that is something I touched on already. If the design team decides that border radius is no longer a thing and we are having square edges everywhere then that is a trivial change to make with SCSS / SASS if you've structured your project correctly and used variables sensibly. With Tailwind this sends you on a goose chase for rounded-* in potentially hundreds of files. That's obviously an oversimplification but hopefully you get the point I'm trying to make here. The answer to poorly structured SCSS is to refactor, not apply Tailwind (and the class soup and mixture of concerns that goes with it). I should probably caveat that with the fact that I'm talking about larger projects here, I can see there's merit in using Tailwind for example if you want to ship a React component like a music player that absolutely must never collide with the selectors of the application it sits in. "Now, it may seem like Tailwind is inline styling and will bring with it the same problems. However, it's not for one key difference: classes." I fail to see how utility classes are any different from inline styling other than the fact that they are shorter. I suppose you can configure them at a project level by overriding them, but surely you are getting into muddy waters when customising "m-auto" so that it doesn't mean margin: auto; any more, as an example? "Tl;dr: I believe Tailwind, amongst other "new" tools in modern web-dev, are coming about because we lost something in recent years. By implementing older tools in modern ways, we are granted the benefit of less mental gymnastics and a better workflow when creating a majority of apps. Newer doesn't always mean better." I can't disagree with that but I respectfully fail to see how Tailwind is better than the numerous alternatives. Tldr from me, Tailwind may well save you having to get intimate with the "Computed" panel and think about stuff but it seems to me that if large changes are made to the design, for example a whitelist or rebrand, then you are going to have a fiendishly difficult time implementing that on a project full of utility classes. With well designed selectors, cascading and variables, it's absolutely trivial to do tasks like that. I am a bit long in the tooth but I know which I prefer.

@zebraforceone This is a wonderful response! Thank you for being one of the rare few online people who are respectful in their discourse. In short, I totally get what you're saying, and I'm not really trying to change your mind. I don't want you to feel like you're doing something wrong or will be left behind if you dont use Tailwind, because I'm very sure there's already other new tools out there that will make Tailwind obsolete and I don't even use it in my professional work, either. I just like it. :) More than anything, I'm trying to help you "get" Tailwind in the way that I do. I also think it's important to state that the best tool for any situation is one that gets the job done in the way you deem best. If your team is comfortable with SCSS and likes using business classes, then that's what you should use. Okay. With that being said... "Yes, not being being engaged in some mental effort and getting comfortable with the 'Computed' panel is, respectfully, in my opinion why people praise the Tailwind hammer :P" I think this is a bit of a strawman argument. I understand the sentiment that it can feel like Tailwind hand-holds people and can teach them bad habits that lead to poor development practices; that I understand. However, there's no reason why, when you use Tailwind for what it is (a library of utility classes with some nice dev-ex), it can be a supplement to other tooling. I disagree that it's a hammer. "The approach my team usually takes is to give each component a unique classname or data attribute, usually matching the components classname" This is exactly the process Tailwind seeks to resolve. Many people (me included) see this as the core anti-pattern with using CSS. There are three parts to this on why I'm opposed to this pattern. 1. Coming up with classnames is a waste of time. It provides little to no benefit outside of the developer experience and they can often be obtuse and unhelpful. There are conventions and decisions you can make that can mitigate the effects of this, but it's all time spent not producing results. 2. Even with tools like SCSS or SASS, these kinds of classnames obfuscate design in other files separate from the components which breaks the component model. Unlike the old way of separation of concerns where you had JS, HTML, and CSS, the fundamental principle of the component model is to combine all of them into one place and separate based on business or technical need. 3. Styling components directly makes the unable to be reused. You can never use any selectors that change general styling, or they will trickle down. E.g. you have a container component that applies display:flex. Inside of this component you have other components that use flex utilities to position and scale themselves. Now, what happens when someone wants to use one of those child components in a different place? They won't be styled correctly, because they're not inside a display: flex. Another core philosophy of the component model is reusability and CSS breaks that, because the behavior isn't isolated to just the component. "If the team decides that border radius is no longer a thing and we are having square edges everywhere, then that is a trivial change with well-structured and sensibly named variables in SASS/SCSS. Tailwind sends you on a goose chase for rounded-* in potentially hundreds of files." In my opinion, this could be hand-waved in a similar way to your first point. "Learn your tooling". Using regex selectors can make you a wizard at doing this and even though it's not fun, I think this is less of a problem than it might seem to be. However, this is the stickiest part of Tailwind, or doing styling in this way at all and I get if it's a turnoff. I would say don't place so much weight on this as no matter what, concessions will need to be made. Blame the person who decided to remove rounding. Lol "The answer to poorly structured SCSS is to refactor, not apply Tailwind (and the class soup and mixture of concerts that goes with it)." That mixture of concerns is intentional. The tradeoff mixing technical aspects in favor of separating components by business concern. It's a fundamentally different way of approaching web-dev. "But surely you're getting into muddy waters when customizing 'm-auto' so that it doesn't mean margin:auto; any more, as an example?" With all due respect, that is a poor example. It, along with many other things, are foot guns. Yes, you can cause a lot of damage by changing something like that, but why would you? I admit I don't know enough to give you a good example of why the classes are better, but without a real-world example of configuration being a bad thing, I think this is a moot point. "I fail to see how Tailwind is better than the numerous alternatives." It's not. It's another tool in your toolbox to be used in specific circumstances, or if you like it. If your app, or development experience would be worse off by using it, then don't! It's no more or less valid to use Tailwind than it would be to use Bootstrap, MaterialUI, or SASS. This is what I meant by the hammer analogy: there's no one right answer to anything. It's better to know what tool to use and why.