You're Using Tailwind CSS The Wrong Way! A look at reuse.

[@ProgramWithErik]

Need some help with a project, level up your skills, React, Next, Vue, or Nuxt? Check out my 1-on-1 mentoring! mentors.to/erik

[@rickyu1978]

was on the fence all this while, you just made our life easier.. we wont be adding tw to our stack and stick with wonderful vanilla css.

[@CStrolx]

So, when I first started looking at Tailwind, I thought. Yeah, that's interesting, that's a new way of doing things. Then I started getting into the thinking, hey, what separates this from inline styles? Classes were intended for us to get away from inline styles and all the repetition involved. I felt that I wanted to do something in my project that represented the semantic classes we are used to, just like you show in the video and saw that this was discouraged and I thought, "why?", it's easier to read and understand, it's not as complicated and it's "DRY", which is important to me. So, as I explored this more carefully, I did come to understand what the author of tailwind was actually saying. In my component framework, I found myself creating a css class that basically matched the name of the parts of my component, almost verbatim. This got me to realize that I wasn't actually writing dry classes at all. I was extracting from my html all the same stuff into a separate file, and in the end, is that actually making things any easier to read and understand, is that actually DRY, or just an over-abstraction? That's when I finally started to get that concept of "hey" if you're repeating yourself inside a component, then one of two things may be happening. You may be applying CSS to individual parts that could be applied at a higher level (like font, for instance), or, ... you could abstract those components into their own sub-components (now that actually is DRY). Now you don't need to write a separate piece of CSS outside of the template, and you can see, at a glance, what that part is supposed to look like. So then I thought about, "What about theming", and Tailwind has ways to handle CSS variables, so theming should be fine. If you need semantic colors and width's and things for your theme, you can abstract those into CSS variables and have those overridden at run time. Also, the way Tailwind has created the atomic classes gets around the performance issues inherent in inline styles. The output is pretty verbose, but with gzip and similar things all that repetition should not be affecting things too negatively. I would not have wanted to use something like Tailwind about 20 years ago before component frameworks and gzip were a thing. For static HTML, it's absolutely horrible. But when you are utilizing a component framework, or simply making custom Web Components, then this approach actually makes a lot of sense.

[@faahkoo]

Splitting it into components it's the only viable way for my dev style. I really hate to look at busy HTML, the most compact it can be for me the better.

[@ProgramWithErik]

I agree

[@rajikkali]

This. 100% Tailwind is DRY if you use proper component structuring

[@m4our4]

using Mojo CSS you can do something like this and reduce lots of code repetition (without leaving the HTML): ... ... ...

[@ShantanuAryan67]

I find myself not using tailwind very much when working with vue/svelte. The build in css solutions are nearly perfect, you can manage scoped/global styles from within the component. I personally recommend css modules + open props with vue. gives me clean html and i can also easily write complex selectors (tailwind's arbitrary varinats are not for me) whenever needed

[@ProgramWithErik]

Thanks for sharing

[@siyedyoussef3202]

also with the css v-bind it's a magic 🪄 scss > tailwind

[@oleksiipylypchuk6746]

What about PrimeVue inner classes? How would you recommend organize them the best way, to maintain the same look across the app. The best I can imagine is using a common css file.

[@SlavZute]

Here's a radical idea - presets Inspired by PrimeVue Tailwind If you think about it - TW classes are just strings, right? So, what if we put the most commonly used combination of these strings into their own variables and share those across components? Obviously, the argument around extra level of abstraction kicks in and keeping the structure of these variables sane comes just like it does when using CSS or SCSS naturally. But at least if you just can't stand the look of your HTML in code editor to the point of it making your eyes bleed and you wake up in cold sweat from the thought of having to update 100s of instances of various components because of new styles... this could be a way to condence those unruly class chains without incurring the costs of @apply 🤔 What do you think, Erik? @ProgramWithErik

[@juanmacias5922]

Your first solution hurt my soul lol I always try to break up my code into components lol

[@chris_ea]

❤ is it any compiler directive that can optimise all code?

[@it_is_ni]

"WET", Write Everything Twice, is not the opposite of DRY. WET is the practice of *waiting* to introduce an abstraction until there's a good enough usecase for abstraction.

[@ProgramWithErik]

That is a good point. That plays into my decision on what I was thinking in this video.

[@СергейКиршевский]

We are using Vuetify, so i decided to wrap every component into Base one. With this approach you could still pass props from the doc to change them, plus you could override them in one place if you need some default features. Even if you need custom design for your project, you could still go this way, replace UI library with CVA and you are good to go

[@acesOfGreen]

I do agree that when using tailwindcss, your html can become quite busy. Using plugins such as Prettier can help tyding it up to make it more readable but still, your html will still look busy. What I have been doing lately is to configure tailwind so I can make use my tailwindCSS classes such as

[@hixday93800]

Hey we use tailwind in our applcations where I work and we most often use the @apply scoped inside the component style when there is a ton of tailwind classes on a single element. Maybe my collegues did use them if there was too much repetition, but I haven't looked at their html that much.

[@aplusphilic]

Extracting components might be a better option for this case and make use of your tools efficiently might be helpful. BTW your VSCode looks clean do you have you configure shared somewhere where I can get inspiration from

[@wookie-1410]

Extract smaller snippets to separate components, for sure. Sometimes, however, you still end up with a component that has very very long "class" attribute. In such situations you can simply try to create multilines (which is possible even with all that prettier config), i.e.: ...

[@mrrolandlawrence]

indeed. shortcuts are great for style layouts. the ones that default for the page - S/M/L etc. then use components. if you are repeating something over and over again, its a great candidate.

[@humansaremortal3803]

For the devs out there "DRY" is okay, there are contexts where its okay to repeat yourself. CSS is one of them. Stop spinning in hamster circle.

[@ProgramWithErik]

Exactly! That’s the point I was making. DRY is great, but in CSS it’s ok to repeat yourself and have multiple utility classes everywhere

[@Stoney_Eagle]

I use the apply directive on a few things but I always stop when I want to make another one and take the time to consider other options. When I know that I need more than 2 of the same elements on the page I just put a v-for in there right away. Yeah tailwind looks messy but it just works so damn well 😊

[@ProgramWithErik]

That makes a lot of sense! I would do the same.

[@nikolaykolev5143]

Splitting into components is the way to go if you work with a framework that supports them. But even there, sometimes you just cannot avoid repeating some stuff (for containers, boxes and general layout). Another thing that I find particularly nasty though is, like in your example, if you have an opacity slider, and you think to do a class interpolation say like opacity-{{ settings.opacity }} that, actually, sadly, won’t work! So you have to do probably a computed property with a swich on settings.opacity with all cases and then return the whole class name for each switch case..which get’s some typing! Sure you can extract those in composables and use everywhere, but still feels sad to have to do it!

[@tmbarral664]

@Erik: No, I disagree. your html should be beautiful. That means easily readable. And that's the point. And to have those very long lines are not pleasant to read. So, yes ,definitively you should go for the component way. I was surprised you started with CSS until the end when I understood this is where you wished to bring us from the beginning ;)

[@DamirSecki]

completely agree... the way tailwind want to enforce utility classes to tightly cuple it to markup and make it totally unreadable is horrible... it is the "only" gripe I have with it! the Markup should be short, semantic, readable and mantainable

[@gveresUW]

I will start off by saying that I have never used Tailwind. I have used Vuetify, which has a bunch of similar utility css classes just like tailwind. I have read a number of people who say tailwind and these utility classes are horrible and go against the design of CSS. In fact they would argue that what you started doing, creating specific classes for specific reused elements, is exactly what css was designed for. I also found the article that you quoted to be suspect. One of the benefits you mentioned for not creating the specific classes was that your CSS bundle would grow in size. Yes, that is true, but in the end, every time you reuse a specific class, your html bundle decreases in size. Look at how many characters you save every time you use the .btn class rather than that string of tailwind utilities. For me, working in Vue, I use the Vuetify utility classes sparingly. I usually use the margin and padding ones because it is so easy to use them to add the extra spacing the layout needs. But then for anything else, I use the or section of vue to produce the component level classes. This is perfect because it puts everything in one file right where I need it and the template html is nice and clean and small. When I am dealing with something that is app wide - like the style of a button, I would create a new component that wraps the button and applies the necessary style. Then reuse that button everywhere. When I decide that yellow buttons are no longer in vogue, I can go to the one place in the code, the app button component, and change the look of it very easily. One file changed and the entire app changes. Styling these reused components everywhere they are used is just asking for a maintenance nightmare.

[@wwizer]

I still use @apply but I also would create child components. I don’t think using @apply is that big of a deal if the scope is limited and it makes sense.

[@ProgramWithErik]

Yeah, maybe just for very small thinks like buttons or certain form elements.

[@robwatson826]

Hey I'd never heard "Write Everything Twice" from anyone else but me, good use

[@kingshanaman]

There's a nice VSCode plug-in that hides all the class text

[@holerisen]

Or even better solution: use CSS modules and use BEM naming. Can‘t argue on that. Clean file, each class has one name that extends all tailwind classes it needs with @apply And then use purgeCSS to remove all unnecessary css.

[@bingers_tv]

Using the @apply is not recommended by Tailwind. I think a better option would be to split your code into components

[@aqibos]

Refactor into React components, and reuse them that way Edit - Oh, I see you landed there in the end 👍

[@krzysztofs3t532]

All this code should be split into few separate components - a Button, Slider, Section, Image. If you think about it you can easily create a polymorphic Button component, with three or four different looks, for example main, secondary, back and default. Then this Index file will have 10 - 15 lines of actual code.

[@MohammedHelewa]

I think it’s not forbidden like if it was in the Bible. But in some cases like working on a page with a very long list of similar items like a page showing movies with different categories.. Think of each item has a cover with shadow layer and a hover effect and favorite button and duration text and other stuff. so in that case not using @apply would become a performance issue as your html becomes very big.

[@it_is_ni]

1: DRY is OK in principle, but abstractions come at a cost. Which Adam points to in the Tailwind docs. So blindly "trying to make everything DRY" is not good advice imho. 2: Every choice (Tailwind, vanilla CSS, frontend framework or not) has pros and cons (benefits and costs). If you choose Tailwind: your HTML is "ugly" but the chances of splash damage when making style changes goes down a lot. If you choose vanilla CSS: it's simple to make far-reaching changes but it's hard to foresee all the effects of a small change (which is compounded in large apps). Using a frontend JS framework requires all people working on a project to learn and know that framework, but it makes certain things more predictable and testable. Using no frontend framework makes it easier to start and ship less code, at the cost of predictability and long term maintenance. 3: There are no perfect abstractions. If somebody tells you otherwise they're trying to sell you something.

[@ProgramWithErik]

Well put.

[@DamirSecki]

NOOOO, not true... if you chose tailwind does not mean your markup is by default ugly. You can use tailwind with @apply and your markup remains clean, your CSS organized in one or few teplmate/theme files. your first point... mothing making blindly is a good advice - doh

[@MaheshwaranVelusamy]

Valid points @it_is_ni

[@mehmetaltinsoy525]

Thanks

[@RIT_Edition]

Daisyui is perfect solution

[@ikbo]

This is why stylex is a better solution

[@wolfphantom]

@apply is not the prescribed way within TailwindCSS. However, if you use it to define a "component" style it should be nested in the @layer component for proper scoping

[@ProgramWithErik]

I went back and forth if I should show Layer and component style, but either way the point stands that a better way is to not use any of them for most use casws

[@wolfphantom]

​@@ProgramWithErikI've occasionally used @apply within a SFC when I needed things that weren't available within Tailwind at the time.

[@PammyStevensonEquest]

Knowing your previous content, this video feels very click bait like. Appreciate for noobs you are making a valid point, but the crux of the video has nothing to do with Tailwind.

[@ProgramWithErik]

I disagree. It’s everything to do with Tailwind

[@PammyStevensonEquest]

@@ProgramWithErik ​I'm probably missing something I guess. Every css framework I've used requires some amount of class concatenation/layering and I would not say that is a tailwind only problem. You have stated in previous videos that we should be using components and your buttons and sliders are the perfect example of where that should be used. Therefore your removal of repetition and desire to be DRY is achieved by using components, regardless of those components still having class layering or custom ".btn" classes. How does using components in this way change the way your using tailwind (or any other css framework)? It doesn't, we're still using css layering which I'd say is by design

[@monikossa9964]

Omg... just delete tailwind. Pos

[@yatagun]

don't use Tailwind at all! This is a complete anti-pattern.

[@ProgramWithErik]

Haha

[@holerisen]

complete bs

[@yatagun]

@@holerisen 💯

[@kingshanaman]

But when you try to use plain CSS you end up creating your own Tailwind, as the project gets bigger.

[@misstress1928]

Tailwind CSS is overrated. Just use a proper CSS methodology and don't bother with so called "benefits" of bloating your markup. TW utility classes mess is hardly manageable, especially if you want to implement a custom design. For something instantly good-looking use classless CSS libraries.

[@danko95bgd]

using tailwind css = wrong from the start

[@ProgramWithErik]

You do you!

[@b1-66er.]

Building reusable components with additional props.

[@ProgramWithErik]

That's my go to. Or using a loop

[@DamirSecki]

No way! I hate components with props that dictates styles! Components should dictate functionality... styles should be extrapolates away from the markup

[@Kingside88]

The clickbait title just sucks. Having 10.000 Components can also be very ugly to be honest. And each component must have a unique name. I think it does not really solve the problem.

[@ProgramWithErik]

This was the recommendation from Tailwind, I agree.

[@ProgramWithErik]

I changed the title

[@znkdev]

nice video, thanks for it, but you spoke, spoke and said nothing, just what everyone thinks about it. haha anyways 👍

[@ProgramWithErik]

If you don't have anything nice to say... maybe don't say it at all. I was going to delete this troll comment, but I'll leave it up