You also no longer have to use `theme` to reference your design tokens in CSS because in Tailwind 4 values are defined as CSS variables removing the need for PostCSS.
You're completely right. For some reason, people always lean to extremes: always using tailwind or never using tailwind. I always use a combination of tailwind + regular css for more advanced stuff such as animations or calc() with variables, and I think it's the best of both worlds.
I think I'm extremely guilty of forcing tailwind to be the only solution in a few projects but I have also started just using normal CSS for really complex stuff. Tailwind is just too hard to understand (for me) when I see a sea of utility classes... Then it's nothing about something being appealing or not, it just slows me down.
But then, the almighty linter arrives, and tells you, to not use custom classes. Unless use Vue, and then bind with :class, at which point it no longer gives a shit... :|
Completely agree, I use both tailwind and css when it is easier or the tailwind becomes too messy, i.e. when it becomes difficult to work out what is going on. Grid and before and after are two such examples. One approach I have used is to specify layout using css (grid), and appearance in tailwind
you earned a subscriber, I like the good advice you are so right on it and i was saying the same thing to my peers. Also you talk fast and get to the point love it
The problem with using tailwind AND regular css is that you will end up with places where conditional styling doesn't apply correctly because of the order/priority. A good example is 90% of the component libraries including shadcn, that have to diff tailwind classes at runtime to figure out what should have priority. There is absolutely no reason to use tailwind in svelte. The purpose of tailwind is to remove the clutter of massive global css files, by moving the styling to the markup so the build step can pick out only the specific rules you use. But in svelte, there are no massive global css files, it's already scoped to the component or page. If you like the color palettes, just set those as vars, without tailwind.
V4 definitely leans into just being css instead of replacing it. I totally agree I like tailwind for the tooling and such but do a lot of the layout and building blocks in regular css then the specific components as well.
Ok, is cool and might be a weapon to end this war on madness. I don't think I'll add it to my simpler projects, but for sure I'll try it if I get to work in a bigger one. Thanks for sharing!
Can you make a explainer on how libraries like how library like Svelte-grid work under the hood (like you raw js explainer of svelte-stores)? and mainly explaining how can we serialise/deserialise a layout (a grid layout) so it can be restored like from localstorage according to user preference, i am finding it hard to understand and there are very less resources on it. Your explainers are fantastic.
Whilst what you're doing here is really cool, you're losing a couple benefits from tailwind. First is the standardisation of tailwind where any dev can pick up on any project assuming the config hasn't changed too much, however with this solution you'd lose some of that (still better than full custom css). The second when breaking out of tailwind and defining custom single-use classes you lose the inline understanding of your elements, while h-[200px] might be a bit ugly and should be avoided where possible it is absolutely readable and any dev can quickly see what is going on rather than having to dive into some stylesheets, find out what each custom class does and then remember that. The reason I love tailwind is that it reduces the mental load on a developer, instead of remembering a myriad of custom css you remember a collection of standardised classes and let the vscode plugin do the rest.
1:15 I was thinking the other day about CSS in the editor, how is that it doesn't add a squiggly lines when you have styles that doesn't apply to the type of element you are using?
I think generating custom themes with Tailwind is not being talked about enough. To me that's the most powerful feature of Tailwind. I can use custom color and spacing tokens and let TW generate that plus a bunch of other helpful utility classes. I don't see much value in default colors from TW because how would I build an app for a client to be in their brand color with predefined colors plus I don't need 20 colors with 10 hues for a project. Generating a custom theme with less tokens also leads to better consistency and less room for error since you have less options to choose from.
i honestly don't see the big deal everyone is making over this new update. i've been using tailwind like this for years, from what i can see v4 just gets rid of the js config file and allows you to set up your own variables right from a css file out of the box. what i do is setup a style-dictionary tokens file that both tailwind and all my base components (styled with regular css) will both extend from. i mainly use tailwind for setting up page layouts, fonts, and the odd edge case when i need to override colors, etc. everyone acting like this is a new paradigm... maybe i should've wrote an article of how i do things lol i may have been ahead of the curve
I really wish the Tailwind docs and their fans would at least mention your POV. They strongly advocate for writing everything in Tailwind, which is madness and sometimes not even possible. Writing regular CSS is promoted as being a nightmare (which is of course nonsense) By the way you don't need Tailwind to get autocompletion for your classes. A quick search brought up the VS code extension " HTML to CSS autocompletion" (which I will try out later). Also, for typing out regular CSS more quickly you can use Emmet. I never write display:flex, just d:f and Tab. There are lots of these examples. I have many concerns with Tailwind and have a lot of evidence (and experience, sigh...) that it introduces maintainability issues (a blog post is being prepared...), but your approach (of including regular CSS as well) at least weakens some of these issues. So thank you for bringing this up. PS: also please keep in mind that some developers have no choice anymore due to misguided management decisions. At my job I am not allowed to write regular CSS / Less anymore, and THAT is a nightmare.
I used tailwind for global stuff. Why make a bunch of dedicated classes just to do a flex center or something. And then I'll use CSS modules for something specific that should be scoped
I have tried Tailwind before and I didn't like it as I am more confident with CSS. As you have mentioned custom naming and not remembering class names I had an identical issues learning to use TW. As I have nothing agains TW I still do not see reason installing extra libs without extra benefits having styles in POSTCSS, Tailwind, App.css, components etc. when I can do the same things with pure CSS (without abstraction layer) using App.css file to set roots and global and have custom styles in components. The last few years CSS is moving rapidly forward and still does. May be one day I will look into TW again but not now. While I like most modern approaches and technologies and big fan of Svelte I personally do not see in TW any added benefits to me. CSS is just more readable to me to set styles I need or easily find and solve any issues 🤷.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
You also no longer have to use `theme` to reference your design tokens in CSS because in Tailwind 4 values are defined as CSS variables removing the need for PostCSS.
can you upload the source code that you use open props to replace inbuilt theme?😊
I just copied the variables from Open Props: github.com/argyleink/open-props.
Open Props still needs PostCSS for removing unused props via postcss-jit-props, right? Or did you find another way of stripping those via Tailwind?
You're completely right. For some reason, people always lean to extremes: always using tailwind or never using tailwind. I always use a combination of tailwind + regular css for more advanced stuff such as animations or calc() with variables, and I think it's the best of both worlds.
I think I'm extremely guilty of forcing tailwind to be the only solution in a few projects but I have also started just using normal CSS for really complex stuff.
Tailwind is just too hard to understand (for me) when I see a sea of utility classes...
Then it's nothing about something being appealing or not, it just slows me down.
Yup, base tailwind covers 95% of situations. For the other 5% you can just use css.
Previous tailwind was overblown garbage. They seem to have become a theme generator which is more useful.
But then, the almighty linter arrives, and tells you, to not use custom classes. Unless use Vue, and then bind with :class, at which point it no longer gives a shit... :|
The next version of Tailwind is pure CSS
I love that you use svelte 5 and tw4 here. This stack has mè so excited for how everything is trending towards simplicity.
I use tailwind + css for production projects at work. Including arbitrary values. It's phenomenal.
The "ranting" style is so entertaining! :D
You made a very good thumbnail, it really pops.
Thank you! 😄
Completely agree, I use both tailwind and css when it is easier or the tailwind becomes too messy, i.e. when it becomes difficult to work out what is going on. Grid and before and after are two such examples. One approach I have used is to specify layout using css (grid), and appearance in tailwind
you earned a subscriber, I like the good advice you are so right on it and i was saying the same thing to my peers. Also you talk fast and get to the point love it
The problem with using tailwind AND regular css is that you will end up with places where conditional styling doesn't apply correctly because of the order/priority. A good example is 90% of the component libraries including shadcn, that have to diff tailwind classes at runtime to figure out what should have priority.
There is absolutely no reason to use tailwind in svelte. The purpose of tailwind is to remove the clutter of massive global css files, by moving the styling to the markup so the build step can pick out only the specific rules you use. But in svelte, there are no massive global css files, it's already scoped to the component or page.
If you like the color palettes, just set those as vars, without tailwind.
V4 definitely leans into just being css instead of replacing it. I totally agree I like tailwind for the tooling and such but do a lot of the layout and building blocks in regular css then the specific components as well.
2:38 ok, I'm on my personal train of hype with open props so now you have my attention 😘
Ok, is cool and might be a weapon to end this war on madness. I don't think I'll add it to my simpler projects, but for sure I'll try it if I get to work in a bigger one. Thanks for sharing!
I love the way you think. Great video man!!
Can you make a explainer on how libraries like how library like Svelte-grid work under the hood (like you raw js explainer of svelte-stores)? and mainly explaining how can we serialise/deserialise a layout (a grid layout) so it can be restored like from localstorage according to user preference, i am finding it hard to understand and there are very less resources on it.
Your explainers are fantastic.
Fantastic, as usual. Thanks.
Whilst what you're doing here is really cool, you're losing a couple benefits from tailwind. First is the standardisation of tailwind where any dev can pick up on any project assuming the config hasn't changed too much, however with this solution you'd lose some of that (still better than full custom css). The second when breaking out of tailwind and defining custom single-use classes you lose the inline understanding of your elements, while h-[200px] might be a bit ugly and should be avoided where possible it is absolutely readable and any dev can quickly see what is going on rather than having to dive into some stylesheets, find out what each custom class does and then remember that. The reason I love tailwind is that it reduces the mental load on a developer, instead of remembering a myriad of custom css you remember a collection of standardised classes and let the vscode plugin do the rest.
So looking forward for v4...
This channel finna blow up someday ong
1:15 I was thinking the other day about CSS in the editor, how is that it doesn't add a squiggly lines when you have styles that doesn't apply to the type of element you are using?
Very nice video and well explained. However, I would like to know which code editor and theme you use?
i want to try this, thanks for you
As someone who likes Tailwind, I just hope they get to a point where they no longer need custom pre-processors and we can just use plain CSS. :)
Great arguments...
How about plugins in alpha? In experimental it works as it was in stable + you can work with your css vars as well
Bro had something he needed to get off his chest today.
There was emotion in it :D
Awesome video
I think generating custom themes with Tailwind is not being talked about enough. To me that's the most powerful feature of Tailwind. I can use custom color and spacing tokens and let TW generate that plus a bunch of other helpful utility classes.
I don't see much value in default colors from TW because how would I build an app for a client to be in their brand color with predefined colors plus I don't need 20 colors with 10 hues for a project. Generating a custom theme with less tokens also leads to better consistency and less room for error since you have less options to choose from.
Intellisense not working at all in vscode with pre-release extension
i honestly don't see the big deal everyone is making over this new update. i've been using tailwind like this for years, from what i can see v4 just gets rid of the js config file and allows you to set up your own variables right from a css file out of the box. what i do is setup a style-dictionary tokens file that both tailwind and all my base components (styled with regular css) will both extend from. i mainly use tailwind for setting up page layouts, fonts, and the odd edge case when i need to override colors, etc. everyone acting like this is a new paradigm... maybe i should've wrote an article of how i do things lol i may have been ahead of the curve
That's the shiny new object syndrome. Because people don't read the docs
I really wish the Tailwind docs and their fans would at least mention your POV. They strongly advocate for writing everything in Tailwind, which is madness and sometimes not even possible. Writing regular CSS is promoted as being a nightmare (which is of course nonsense)
By the way you don't need Tailwind to get autocompletion for your classes. A quick search brought up the VS code extension "
HTML to CSS autocompletion" (which I will try out later). Also, for typing out regular CSS more quickly you can use Emmet. I never write display:flex, just d:f and Tab. There are lots of these examples.
I have many concerns with Tailwind and have a lot of evidence (and experience, sigh...) that it introduces maintainability issues (a blog post is being prepared...), but your approach (of including regular CSS as well) at least weakens some of these issues. So thank you for bringing this up.
PS: also please keep in mind that some developers have no choice anymore due to misguided management decisions. At my job I am not allowed to write regular CSS / Less anymore, and THAT is a nightmare.
I used tailwind for global stuff. Why make a bunch of dedicated classes just to do a flex center or something. And then I'll use CSS modules for something specific that should be scoped
I have tried Tailwind before and I didn't like it as I am more confident with CSS. As you have mentioned custom naming and not remembering class names I had an identical issues learning to use TW. As I have nothing agains TW I still do not see reason installing extra libs without extra benefits having styles in POSTCSS, Tailwind, App.css, components etc. when I can do the same things with pure CSS (without abstraction layer) using App.css file to set roots and global and have custom styles in components. The last few years CSS is moving rapidly forward and still does. May be one day I will look into TW again but not now. While I like most modern approaches and technologies and big fan of Svelte I personally do not see in TW any added benefits to me. CSS is just more readable to me to set styles I need or easily find and solve any issues 🤷.
💯
Why not just use the style tag? 🤣
embrace modern css, awesome
"Brother in Christ, just use CSS" 🤣🤣
What in the world... I'm halfway through the video and you haven't said anything about tailwind 4 theming
Then watch it completely before writing a comment?
Can someone explain to me why to use open-props with tailwind at all?
Haters gonna hate
Tailwind as variables would be great.
why ru using Linux?
I'm not your friend 😡
Fun fact, you don't even have to think about CSS classes when you use CSS-in-JS
every css in js solution is bad. unreadable garbage
@@KhoeMoiNgay-uf4zw Objectively false, and rather ignorant.
Tailwind 4+ open props/daisyui /unocss for "big projects"
Picocss/sass (though I am liking pico more) for blogs /simple website