Earlier quoted context omitted.
The point is that it’s ridiculously fast to build and extremely easy to maintain. It’s also not hard to read after, idk, a week of working in it? The only people I’ve seen struggle beyond that are people who dug in their heels and dogmatically decided to struggle with it. FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a element.
I strongly disagree on the maintainability. Mistakes are easy to make and have been made when comparing a list of 20 class names across a dozen elements. Its only "maintainable" if you ignore the class list when reading. I review my local evangelists' tailwind code and from their mistakes its clear they're not reading the class list. It reminds me of how some people claim they're great at multitasking and can text &…
Show HN: Tailwind Template Directory
61–70 of 81 posts
Re: Show HN: Tailwind Template Directory
#62A lot of Tailwind's value comes not from the utility classes, but from the design system they enforce on the user, which is the most valued feature Tailwind offers, in my opinion.
I’ve always had the idea of producing a CSS design system with just a bunch of preset CSS variables to use like ‘margin-left: var(—-p2);’, as it’s close to how I end up using Tailwind lately; ‘@apply ml-2;’
Re: Show HN: Tailwind Template Directory
#63Earlier quoted context omitted.
> FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a element. Sure thing. What I don't understand though is why not put a Button.css file next to the Button element file, and describe all the button styles in there. What's so hard about building or maintaining that?
Soon after, you're going to need slightly adjust that button, you will add some helper classes. Then there will be a case when base style of that button doesn't work with new button style, and now you have 2 bases for a button. You might have semantically named those buttons, but 3 months later that no longer makes sense, and now you're afraid to rename it. Tailwind lets you style elements in the same file as the ele…
The proper thing to do, in my mind, is to gradually set up a collection of such buttons (and other components), and document their properties. A design system, if you will. You shouldn't have that many button variations.
This should also help with the "3 months later" case. Once you've catalogued your buttons, you can reason about them, update their styles, rename them as you please, and so on, while maintaining consistency of buttons across your site.
Re: Show HN: Tailwind Template Directory
#64Earlier quoted context omitted.
The point is that it’s ridiculously fast to build and extremely easy to maintain. It’s also not hard to read after, idk, a week of working in it? The only people I’ve seen struggle beyond that are people who dug in their heels and dogmatically decided to struggle with it. FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a element.
It's adequate for some folks who work in the same codebase, and define their own style of work. It's been a real pain for me who comes in to various codebases for short periods of time and have to read/digest/learn every single project's unique take on buttons. class="btn btn-primary" is also pretty easy to read. But in the last couple weeks I've have to deal with both class="bg-blue-500 hover:bg-blue-600 text-white…
Wouldn't you have to scan disparately located CSS files anyway? How many projects have you seen with nonsensical or clobbered classnames or conflicting rules?
Really for a lot of designs I think you can just eyeball it. If `px-4` looks about right, then use it. Otherwise you can find a similar component and hijack the exact padding if you want, or get it from the design.
You probably think @apply makes more sense because you know and like traditional CSS. You want to apply tailwind classes and condense them into a single reusable one. Tailwind asks you to think in a different way. The classes are aptly named (mostly) and granular (one class per css directive), so my knowledge of CSS felt very transferable.
Imo should be
Leveraging something like Class Variance Authority or more simply:
Using tailwind-mergeI have found tailwind to be indispensable, and it pairs particularly well with React.
Re: Show HN: Tailwind Template Directory
#65I have been using 3.5 sonnet to generate me tailwind components it does a pretty good job, and then with clsx, tailwind-merge and tailwind-variants things become pretty maintainable. I reach-out to shadcn-svelte when I need components which would take some extra tuning.
Re: Show HN: Tailwind Template Directory
#66Earlier quoted context omitted.
I’ve always had the idea of producing a CSS design system with just a bunch of preset CSS variables to use like ‘margin-left: var(—-p2);’, as it’s close to how I end up using Tailwind lately; ‘@apply ml-2;’
Why use @apply for this? The classes are already simple and standardized. Now if I want to modify a component style I have to go find the css file with the @apply rule, which is how css normally used to work & kind of defeats the point of Tailwind IMO. I also have to grep the whole codebase and make sure nobody was using `.card-bg` or whatever in an unexpected spot. Plus you have to deal with a mixture of bespoke CSS…
My own CSS is classic BEM style, so very component like.
In hindsight I could easily replace Tailwind and just produce a set of CSS variable as a design system.
Re: Show HN: Tailwind Template Directory
#67I have been using 3.5 sonnet to generate me tailwind components it does a pretty good job, and then with clsx, tailwind-merge and tailwind-variants things become pretty maintainable. I reach-out to shadcn-svelte when I need components which would take some extra tuning.
Same. 3.5 Sonnet seems particularly good at React and Tailwind. I'm moving away from other frameworks and libraries to React and Tailwind because of this.
Maybe the most automated solution will become the meaning of 'best tool for the job'.
The only positive I can see from this is that it should push maintainers towards stabilization faster as large API changes would result in huge productivity losses. Already true but perhaps more clear when the LLM starts producing failing tests.
Re: Show HN: Tailwind Template Directory
#68Earlier quoted context omitted.
You lost me at ‘maintain’. It’s definitely not easier than just updating a single .button class, and I’m not going to create reusable components out of everything in my project, the approach doesn’t work for everything.
Yes, it is easier to maintain (assuming no css-in-js) Your styles are bound to the component, not some global in your app. States and their representations are controlled in the component themselves With normal css files and class names, you must jump between files. With tailwind, I see what's going on with a component right in my jawascript
If I used tailwind utility classes, how do I update my data table styling without having to search and replace across all of my files? Assuming you could even search and replace, the utility classes could be in a different order. Not saying it’s not doable, but it seems like a real pain in the ass. What am I missing?
Re: Show HN: Tailwind Template Directory
#69Earlier quoted context omitted.
Have you used MUI before? No need for utility classes, no need for writing custom selectors, everything ties back to the theme, and everything is consistent. I don’t believe that “80-95% of the time utility classes are better” when super popular alternatives like MUI exist. Tailwind introduces some solutions while introducing other problems. It has its place when used correctly, but I’ve never seen a single TW codeba…
Do you mean this MUI? https://github.com/muicss/mui Last commit was four years ago and it has some weird bugs, eg this page tells me "Warning: Your browser does not support WebComponents" when Mobile Safari most definitely does. https://www.muicss.com/docs/v1/webcomponents/buttons (Filed an issue: https://github.com/muicss/mui/issues/338 )
Re: Show HN: Tailwind Template Directory
#70Earlier quoted context omitted.
Have you used MUI before? No need for utility classes, no need for writing custom selectors, everything ties back to the theme, and everything is consistent. I don’t believe that “80-95% of the time utility classes are better” when super popular alternatives like MUI exist. Tailwind introduces some solutions while introducing other problems. It has its place when used correctly, but I’ve never seen a single TW codeba…
But MUI is nothing else then all the CSS-Frameworks before, only that you like the syntax more.
The difference is that it comes with a component (and of course more), which has different variants, and you can set default props and default styles at the theme level.
So where an outlined button in a utility CSS world is class="... ... ... ...", or figuring out a way to be able to express that with class="button button-outlined", in MUI and Joy it's