Guys, it's okay to use both Tailwind AND css at the same time especially for relational or complex styles. For some reason a lot of people think you must stick to one or the other when you don't.
Yeah, you’re not wrong. My general preference is to not use tailwind. For me, I use it on projects I don’t touch much because I don’t need to figure out the design system. When I mix the two, it ends up defeating the purpose. While you could create classes for this, it would get pretty messy. But you’re not wrong and a little vanilla CSS would make a lot of things easier in a lot of tailwind projects.
@@CodinginPublic That's true, and having both css and Tailwind together means you potentially have to look in two places for your component which is no fun. That said, I think going all in with css or using Tailwind for the to-the-element styling and sprinkling in css for the more complex properties or relational styles is probably the best setup. This might be a hot take, but best to stick with web fundamentals like css instead of massaging Tailwind to do every complex thing, but there's no denying the speed and good defaults Tailwind provides to quickly lay the groundwork.
lol yeah. That’s one of the reasons I typically don’t like to modify tailwind much. One of the only reasons I reach for tailwind is so I don’t have to remember my design system when jumping into an old project. So add too much custom and suddenly you can’t remember anything.
That’s pretty cool! I have the exact same functionality in my postcss config file. I use postcss-functions to create this clamp function. And I use it as an arbitrary value like. “text-[fluid(min_value,max_value,min_breakpoint,max_breakpoint,rem_base_value)]” “text-[fluid(1rem,3rem)]” The last 3 arguments are optional To be honest my function seems a bit more easy to read but I love know that I’m not only one actively trying to avoid Media queries 😂 Let’s make fluid all the things!!!
Sadly, a lot of people are missing the point entirely. This plugin in is extremely helpful while developing. It makes the templates cleaner because you can have a single class instead of 2, 3, 4 or even more. So it's less work to write and keeps everything cleaner. The fluidity in the frontend is just an additional bonus in my opinion and not the main benefit. And it's also not only useful for text-size (main use-case of clamp() for most people) but great for other things too, especially margin and padding.
Agreed. I do think the fluidity ends up making better looking designs at each breakpoint, but for tailwind specifically the number of classes you’re writing is probably the bigger deal like you mention. And yes, padding, gap, margin, etc. are amazing with clamp.
It's cool, but I feel like I'm worried about performance and I don't know how much users care about "fluidity" between different layouts for their media devices. This resize of the window back and forth is something really only developers do lol...
There's no reason it'd be bad for performance since it's a native css function and the idea is that your margins/paddings/gaps/font-sizes scale nicely for every strange screen size. For example, with the traditional approach of having 3 or 4 breakpoints, you could have the font size on a large tablet be the same size as an ultra wide screen which may look a little funny. Not a huge deal for sure but small quality of life improvement and wayyyy less media queries :)
@@joshuamitchell6204 Yeah, totally fair! I just hope that devs who stumble on this can maybe use this as an excuse to make their websites more responsive haha.
It’s not so much that the jumping is the problem. Rather, it’s nice to have the font size dynamically adjust for instance or the padding dynamically adjust so it always fits the screen, whatever the size. Clamp is a native CSS feature, but perhaps there’s a performance concern I don’t know about?
@@joshuamitchell6204 Being native doesn't mean that it doesn't affect performance. Using clamp means the browser is doing calculations to find the current value. If you have a complex layout with many uses of clamp() then there will be a performance impact.
I don't understand, the plugin helps to make responsive font sizes for different screen sizes? It's old technology, was always hard to implement for real world projects, or I misunderstood something.
Ey up, do you have any videos on developing dynamic Astro components using Tailwind? I've bought your course, and watched a few of your videos but those use custom CSS classes as opposed to dynamically applying Tailwind classes to change things like size, theme, etc.
I’ve used tailwind on lots of projects before on the channel. I also use it later on in the course quite a bit. The nice thing is the tutorials don’t need to be Astro specific as tailwind is tailwind no matter where you use it! :)
I’ve wanted to like fluid for almost a year now, but I’ve really never been able to get it to work as expected. The docs have never worked except for a very old package version which couldn’t build because of broken dependency links.
@@CodinginPublic It’s been a minute, I was using ```"fluid-tailwind": "^0.1.6",```. The old docs said to include fluid, and fluidCorePlugins, in the tailwind confit.plugins array, needed an extract: fluidExtractor(), and it hardly ever worked. Was very fiddly. It seems like this vid is a great demo of how to quickly add it to a project now, so thanks!
Too fiddly and time consuming for me. I prefer just putting a single clamp on the html font size since TW uses rems anyway. You get the same effect albeit with less granular control.
It took what, only 3 years to implement the clamp feature? Tailwind team sometimes are weird. This stuff should have been there long time ago. Its the same with nth child etc, you have to create a custom function to make it work. Or at least it used to be the case not so long ago. I wonder if it's finally here. I'm criticizing but I love Tailwind, especially with Shadcn integration.
I’m sure there have been other implementations. There are ways to do clamp functionality by rolling your own functions, too, or of course you can just write vanilla CSS, but this is one of the reasons I usually prefer writing my own CSS design systems. You can’t really write successful Tailwind unless you know CSS, so Tailwind is a great option if you already know CSS. And knowing CSS lets you break out of the system whenever you need to.
Guys, it's okay to use both Tailwind AND css at the same time especially for relational or complex styles. For some reason a lot of people think you must stick to one or the other when you don't.
Yeah, you’re not wrong. My general preference is to not use tailwind. For me, I use it on projects I don’t touch much because I don’t need to figure out the design system. When I mix the two, it ends up defeating the purpose. While you could create classes for this, it would get pretty messy. But you’re not wrong and a little vanilla CSS would make a lot of things easier in a lot of tailwind projects.
@@CodinginPublic That's true, and having both css and Tailwind together means you potentially have to look in two places for your component which is no fun. That said, I think going all in with css or using Tailwind for the to-the-element styling and sprinkling in css for the more complex properties or relational styles is probably the best setup. This might be a hot take, but best to stick with web fundamentals like css instead of massaging Tailwind to do every complex thing, but there's no denying the speed and good defaults Tailwind provides to quickly lay the groundwork.
I used to have similar functionality using font-size: 1vw but it was more hassle than it was worth. Removing it years later was another headache.
lol yeah. That’s one of the reasons I typically don’t like to modify tailwind much. One of the only reasons I reach for tailwind is so I don’t have to remember my design system when jumping into an old project. So add too much custom and suddenly you can’t remember anything.
That’s pretty cool!
I have the exact same functionality in my postcss config file.
I use postcss-functions to create this clamp function.
And I use it as an arbitrary value like.
“text-[fluid(min_value,max_value,min_breakpoint,max_breakpoint,rem_base_value)]”
“text-[fluid(1rem,3rem)]”
The last 3 arguments are optional
To be honest my function seems a bit more easy to read but I love know that I’m not only one actively trying to avoid Media queries 😂
Let’s make fluid all the things!!!
Wow. That’s brilliant. I might steal that!
Sadly, a lot of people are missing the point entirely. This plugin in is extremely helpful while developing. It makes the templates cleaner because you can have a single class instead of 2, 3, 4 or even more. So it's less work to write and keeps everything cleaner. The fluidity in the frontend is just an additional bonus in my opinion and not the main benefit. And it's also not only useful for text-size (main use-case of clamp() for most people) but great for other things too, especially margin and padding.
Agreed. I do think the fluidity ends up making better looking designs at each breakpoint, but for tailwind specifically the number of classes you’re writing is probably the bigger deal like you mention. And yes, padding, gap, margin, etc. are amazing with clamp.
I was playing around with this like literally yesterday haha and you posted a video about it.
Haha nice!
It's cool, but I feel like I'm worried about performance and I don't know how much users care about "fluidity" between different layouts for their media devices. This resize of the window back and forth is something really only developers do lol...
There's no reason it'd be bad for performance since it's a native css function and the idea is that your margins/paddings/gaps/font-sizes scale nicely for every strange screen size. For example, with the traditional approach of having 3 or 4 breakpoints, you could have the font size on a large tablet be the same size as an ultra wide screen which may look a little funny. Not a huge deal for sure but small quality of life improvement and wayyyy less media queries :)
@@joshuamitchell6204 Yeah, totally fair! I just hope that devs who stumble on this can maybe use this as an excuse to make their websites more responsive haha.
In complete agreement.
It’s not so much that the jumping is the problem. Rather, it’s nice to have the font size dynamically adjust for instance or the padding dynamically adjust so it always fits the screen, whatever the size. Clamp is a native CSS feature, but perhaps there’s a performance concern I don’t know about?
@@joshuamitchell6204 Being native doesn't mean that it doesn't affect performance. Using clamp means the browser is doing calculations to find the current value. If you have a complex layout with many uses of clamp() then there will be a performance impact.
I don't understand, the plugin helps to make responsive font sizes for different screen sizes? It's old technology, was always hard to implement for real world projects, or I misunderstood something.
It just allows you to use the modern CSS clamp function easily in Tailwind without writing your own custom CSS.
Can you add that actually to shadcn components? Looks pretty promising.
Yep. Should be able to since you’re just installing shadcn components.
Ey up, do you have any videos on developing dynamic Astro components using Tailwind? I've bought your course, and watched a few of your videos but those use custom CSS classes as opposed to dynamically applying Tailwind classes to change things like size, theme, etc.
I’ve used tailwind on lots of projects before on the channel. I also use it later on in the course quite a bit. The nice thing is the tutorials don’t need to be Astro specific as tailwind is tailwind no matter where you use it! :)
I’ve wanted to like fluid for almost a year now, but I’ve really never been able to get it to work as expected. The docs have never worked except for a very old package version which couldn’t build because of broken dependency links.
Huh. I didn’t run into anything. What issues are you having specifically? Any chance it’s related to that config for screens?
@@CodinginPublic It’s been a minute, I was using ```"fluid-tailwind": "^0.1.6",```. The old docs said to include fluid, and fluidCorePlugins, in the tailwind confit.plugins array, needed an extract: fluidExtractor(), and it hardly ever worked. Was very fiddly. It seems like this vid is a great demo of how to quickly add it to a project now, so thanks!
I think the screens may have been a thing too now that you mention it.
So useful!
Glad it's helpful!
Too fiddly and time consuming for me. I prefer just putting a single clamp on the html font size since TW uses rems anyway. You get the same effect albeit with less granular control.
Yeah, that’s what I’ve always done. I think this might stick for me, but I understand it’s not for everyone.
It took what, only 3 years to implement the clamp feature? Tailwind team sometimes are weird. This stuff should have been there long time ago. Its the same with nth child etc, you have to create a custom function to make it work. Or at least it used to be the case not so long ago. I wonder if it's finally here.
I'm criticizing but I love Tailwind, especially with Shadcn integration.
I’m sure there have been other implementations. There are ways to do clamp functionality by rolling your own functions, too, or of course you can just write vanilla CSS, but this is one of the reasons I usually prefer writing my own CSS design systems. You can’t really write successful Tailwind unless you know CSS, so Tailwind is a great option if you already know CSS. And knowing CSS lets you break out of the system whenever you need to.
thx mr. Astro-hero got a question, what do you think about the AHA stack? i mean astro, tailwind, alpinejs and htmx? of course with astroDB❤
lol. I think it make sense for a lot of basic interactive sites :)
lol. I think it make sense for a lot of basic interactive sites :)
@@CodinginPublic thx for your reply... would you think this could be the most easiest way to build an application?