this isn't different from inline style... what if you have to change text align, margin, or background color? Normally this is a css job, but with this markup you have to change your html for every cosmetic change.
If you really want to use the Tailwind classes, give your nav a single classname (like, i don't know, class="main-navbar"), then in your scss extend all the Tailwind classes under .main-navbar. This way you can leave your html clean and independent from the styling.
Your thought was my initial thought also but I have revisited it.
Keeping it in the html is not as big of a issue as it use to be. It also makes it more portable, unless you are using plain css files or something that is not css in js.
This is how tailwind was designed to be used. Yes you can compose new classes with it. But that is really just making more work on yourself.
In modern web dev, like the Vue app he built, he most likely has single file components. So now if he wanted to adjust the nav bar, he will be going into that file anyways.
The big argument you are making are multiple instances of a piece of html across the site. Well, with modern development by making components you only have one place for that code in development. So it’s not extra work.
Additionally my teams have switched to TailwindCss and with the inline classes have found a few things.
It’s faster to develop because the syntax is shorter and your not opening another file or moving to the style block in the same file.
They still need to know css, unlike bootstrap.
Code reviews have become easier, because you are not mapping classes declared somewhere else and the styles to the html.
Naming things is hard, now they do a lot less of that.
Our extensions have been pretty minimal, same with overrides, yet we do not look like what you might assume the theme is.
Because of many of these reasons, we may even use Alpine JS in the next project.
So I know this goes against conventional wisdom. I have been at this for almost 20 years and totally understand where your coming from. But as you can see I have come around.
Extending makes sense if you're doing something multiple times over and over, like cards for instance or alerts. But utility first gives you far more fine grained control over your presentation.
You'll notice even boostrap has added many utility classes to mimic the tailwind paradigm.
Thanks for the code OP, this was very useful.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi,
nice article!
But please, avoid doing things like:
this isn't different from inline style... what if you have to change text align, margin, or background color? Normally this is a css job, but with this markup you have to change your html for every cosmetic change.
If you really want to use the Tailwind classes, give your
nava single classname (like, i don't know,class="main-navbar"), then in your scss extend all the Tailwind classes under.main-navbar. This way you can leave your html clean and independent from the styling.Your thought was my initial thought also but I have revisited it.
Keeping it in the html is not as big of a issue as it use to be. It also makes it more portable, unless you are using plain css files or something that is not css in js.
This is how tailwind was designed to be used. Yes you can compose new classes with it. But that is really just making more work on yourself.
In modern web dev, like the Vue app he built, he most likely has single file components. So now if he wanted to adjust the nav bar, he will be going into that file anyways.
The big argument you are making are multiple instances of a piece of html across the site. Well, with modern development by making components you only have one place for that code in development. So it’s not extra work.
Additionally my teams have switched to TailwindCss and with the inline classes have found a few things.
It’s faster to develop because the syntax is shorter and your not opening another file or moving to the style block in the same file.
They still need to know css, unlike bootstrap.
Code reviews have become easier, because you are not mapping classes declared somewhere else and the styles to the html.
Naming things is hard, now they do a lot less of that.
Our extensions have been pretty minimal, same with overrides, yet we do not look like what you might assume the theme is.
Because of many of these reasons, we may even use Alpine JS in the next project.
So I know this goes against conventional wisdom. I have been at this for almost 20 years and totally understand where your coming from. But as you can see I have come around.
I've been working with Tailwindcss for more than a year and I could not put into words, what is like to work with it. Kudos to these arguments
Bravo ... that's exactly what I was thinking.
Extending makes sense if you're doing something multiple times over and over, like cards for instance or alerts. But utility first gives you far more fine grained control over your presentation.
You'll notice even boostrap has added many utility classes to mimic the tailwind paradigm.
Thanks for the code OP, this was very useful.