I have been using tailwind. One thing I've noticed is that it can become unmaintainable compared to styled-components since you just have divs with classes (and it's hard to read 50 nested divs).
Has anyone used something like Tailwind-Styled-Component [1] and found it worthwhile?
From what I gather from the docs is that tailwind and atomic css is designed for you to colocate the styling in the html so you can avoid having to create a CSS version of a component along with an HTML version of a component.
For example, in CSS you could create a class for a card called “.card”, but this by itself does not create a card component as you may need card-title within it and card-wrapper on the outside, and various other styles that may seem like they are reusable subcomponents but are not. And it’s a misnomer because it may require a more complicated HTML structure and you cannot just create a div and apply a class “card” and get back the component.
Instead in a real app your component has an HTML structure, a css structure, and the reusable package you put it in may be the react component, and not style called “card” that you can use.
Tailwind advocates for making your components reusable on this framework level (whether vue or react), rather than at the CSS level. Because even if your make your CSS reusable you still have to recreate the HTML structure. And if you put your HTML in a reusable component and also have a set of reusable styles then you have a Card component concept and a Card style concept that becomes redundant.
To address your specific problem, if your code is unreadable due to inline tailwind styles then it’s a sign you should be breaking the HTML into reusable sub components instead.
I especially like how easy it is to fall back onto ordinary Styled Components if I'm trying to implement things more specific than what tailwind can handle.
hmm, maybe HN related problems? Application error: a client-side exception has occurred (see the browser console for more information), some nextJS issue, so maybe server side?
Curious what counts as unmaintainable for you. The HTML is certainly uglier, but cost-of-copy-paste is very low compared to cost of maintaining abstractions. That for me is the primary value add for Tailwind.
Nice collection. The site is annoying to navigate with the back button on mobile, I have to hit back multiple times to get to the component categories page. I guess it's using pushState so you can easily link directly to a particular component by copying the URL, which is a neat feature, but I think it should use replaceState instead to not mess with the back button.
Hello, creator of HyperUI here. Thanks for your feedback, however this is not something I have added or can replicate. Could it be an extension you're using that's causing it?
They've gone full circle: this is bootstrap implemented in tailwind. How funny.
EDIT: It is funny because I've been looking for something opinionated like Bootstrap, but that can be tree-shaken to a smaller package, like Tailwind, but I don't want have to redesign every dang component.
Similar for me, Next.js / Daisy + Tailwind / Firebase means I can whip out a MVP or prototype in weeks instead of months. Love the increase in productivity first tooling in web development ecosystem.
Excited to see more re-usable components based on tailwind, but have also really come to appreciate the tailwind ui model for helping support open source. The core of tailwind is still there and free to use, but tailwind ui gives a premium option for a lot of off the shelf components that I have issue at all paying for.
I know some have pointed out in other threads they wish tailwind ui components were more of a complete working example with Alpine examples included, it's a fair complaint and area of improvement. But overall I don't have any issue with the model for tailwind ui.
Nope. Some people don't want fuss over UI to the extent that tailwind forces you. Some of us want an opinionated Sass-based framework out of the box. The only advantage I've found using Tailwind is anal-level control over details when bootstrap already has a uniform ecosystem with far, far fewer classes. The former requires way more upfront cost to get running, where the latter is done at day one. Only downside is the tree-shaking in bootstrap, it would be nice if it could be made smaller during a Next/Nuxt/webpack build.
These tailwind component libraries make little sense if you compare them directly to bootstrap without wanting to work with tailwind.
Tailwind is in every way superior when you are implementing a bespoke design, you develop faster, your CSS is small and less complex, the output is performant, you have a uniform mini-language, if you apply some up front analysis of a design/-system you can generate 90% of your CSS from a normalized configuration.
Now compare that to fighting default styles and complected component styles, applying overrides, extending via SCSS variables and generating your own CSS utilities with SCSS. It's pretty night and day for this use-case.
Component libs for tailwind that compress the classes are a bit funny and IMO you don't get much benefit from them other than playing nice with tailwind. You might have a reason to use tailwind but want predefined component classes? But then you get the same disadvantage that component based libraries like bootstrap have, so the choice is arbitrary here.
What makes _much_ more sense is what tailwindui does, they give you the raw source, so you get to write out of the box components quickly but can pull them apart without friction.
I expect Bootstrap will live on for a long time, but the era of it being either the trendy or obvious choice is over.
When Bootstrap debuted, its big strength was that it gave you a decent UI for little effort, at a time when the popular alternative was `vim styles.css`.
Needs and tools have shifted. Fewer projects get their UI from a programmer with no design sense. More projects need more widgets that aren't available off-the-shelf. Component-based web frameworks make it easier to build reusable widgets in-house.
(I think in didn't help that it took Bootstrap forever to stop depending on jQuery, and SPAs got popular and didn't need jQuery but did need to reduce page weight)
Not for me. Bootstrap is very mature, has sane UX, is adaptable, has a good balance between general styles and utility classes. I find that Tailwind clutters your HTML and I fail to see the benefit over writing pure CSS in isolated components in a framework like e.g. Svelte. The reason I would use a CSS framework in the first place is to avoid having to write everything from scratch myself. All (the free parts of) Tailwind affords is an indirect way of writing styles using classes. In that case you might as well bite the bullet and learn CSS properly.
Think about it this way, most developers should have been familiar with CSS, utility classes is a shorthand that make its easy to remember and find user defined class if you have tried Tailwind 3, I found it solve all of my checklists.
Like Bootstrap way, you can still define that with Tailwind classes either in input.css with @apply directive (abstract out utility classes from HTML) or Tailwind configuration. It’s a way to speed up our development.
Readit News
Has anyone used something like Tailwind-Styled-Component [1] and found it worthwhile?
https://www.npmjs.com/package/tailwind-styled-components
For example, in CSS you could create a class for a card called “.card”, but this by itself does not create a card component as you may need card-title within it and card-wrapper on the outside, and various other styles that may seem like they are reusable subcomponents but are not. And it’s a misnomer because it may require a more complicated HTML structure and you cannot just create a div and apply a class “card” and get back the component.
Instead in a real app your component has an HTML structure, a css structure, and the reusable package you put it in may be the react component, and not style called “card” that you can use.
Tailwind advocates for making your components reusable on this framework level (whether vue or react), rather than at the CSS level. Because even if your make your CSS reusable you still have to recreate the HTML structure. And if you put your HTML in a reusable component and also have a set of reusable styles then you have a Card component concept and a Card style concept that becomes redundant.
To address your specific problem, if your code is unreadable due to inline tailwind styles then it’s a sign you should be breaking the HTML into reusable sub components instead.
I have my Tailwind css in a global.css file. That's my solution for making it readable.
I especially like how easy it is to fall back onto ordinary Styled Components if I'm trying to implement things more specific than what tailwind can handle.
Here's a sample of what I've implemented with twin.macro: https://grueplan.com
``` <Question> {...} <Footer> < button> { ... } </button> <QuestionBadge> </QuestionBadge> </Footer> </Question> ```
That's easier than
``` <div className = " ... "> { ...} <div> <div> </div> ```
https://windicss.org/posts/attributify.html
EDIT: It is funny because I've been looking for something opinionated like Bootstrap, but that can be tree-shaken to a smaller package, like Tailwind, but I don't want have to redesign every dang component.
Of the SPAs, companies want React and people to “hit the ground running”
They dont recognize Vue as that
I know some have pointed out in other threads they wish tailwind ui components were more of a complete working example with Alpine examples included, it's a fair complaint and area of improvement. But overall I don't have any issue with the model for tailwind ui.
Deleted Comment
i keep a list of these libraries here https://github.com/sw-yx/spark-joy/blob/master/README.md#tai... and just gave it a little star to demonstrate quality
Tailwind is in every way superior when you are implementing a bespoke design, you develop faster, your CSS is small and less complex, the output is performant, you have a uniform mini-language, if you apply some up front analysis of a design/-system you can generate 90% of your CSS from a normalized configuration.
Now compare that to fighting default styles and complected component styles, applying overrides, extending via SCSS variables and generating your own CSS utilities with SCSS. It's pretty night and day for this use-case.
Component libs for tailwind that compress the classes are a bit funny and IMO you don't get much benefit from them other than playing nice with tailwind. You might have a reason to use tailwind but want predefined component classes? But then you get the same disadvantage that component based libraries like bootstrap have, so the choice is arbitrary here.
What makes _much_ more sense is what tailwindui does, they give you the raw source, so you get to write out of the box components quickly but can pull them apart without friction.
When Bootstrap debuted, its big strength was that it gave you a decent UI for little effort, at a time when the popular alternative was `vim styles.css`.
Needs and tools have shifted. Fewer projects get their UI from a programmer with no design sense. More projects need more widgets that aren't available off-the-shelf. Component-based web frameworks make it easier to build reusable widgets in-house.
(I think in didn't help that it took Bootstrap forever to stop depending on jQuery, and SPAs got popular and didn't need jQuery but did need to reduce page weight)
Like Bootstrap way, you can still define that with Tailwind classes either in input.css with @apply directive (abstract out utility classes from HTML) or Tailwind configuration. It’s a way to speed up our development.
Except 5.1 that broke my homemade dark theme implementation with their use of css variables ;)
Deleted Comment
Quick feedback on the website: The left side of the components preview pages falls off the left side of my screen (Chrome, 13'' Mac).