Earlier quoted context omitted.
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 &…
I’ve experienced the exact same thing. Most TW evangelists I know are admittedly not that great at CSS. Those who are generally prefer a library like MUI instead, which offers the same maintainability benefits, a far more consistent UI, but with a higher learning curve.
Show HN: Tailwind Template Directory
41–50 of 81 posts
Re: Show HN: Tailwind Template Directory
#42Earlier quoted context omitted.
So that’s a mid blue button that gets slightly darker on hover, with bold white text, it’s got a little more horizontal padding than vertical padding and has slight corner rounding and a slight drop shadow. And I can see all of that in context where the button is declared rather than having to go look at another file and see what everything is. Oh and I know that none of those TW classes conflict or over write any pr…
Good luck changing the style site-wide.
Secondly, with the componentization of web apps this is largely quite simple from a code perspective. All the other complexities remain but changing a Tailwind styled button isn't much hard than changing a CSS class.
Lastly, designers are moving to design tokens applied in Tailwind config or CSS vars. This decouples the colors from the classes and turns them into config that's exported from an app like Figma, with tools to automate that export as a git PR if you're feeling technical.
These things were hard to do. People in front end tech have thought about that and built tools to make it a lot easier.
Re: Show HN: Tailwind Template Directory
#43Earlier quoted context omitted.
Good luck changing the style site-wide.
A few points on that. First, in 25 years of front end dev at scale I can't think of a time when a site I've worked on has ever actually made a site wide change to the styling without it being a big deal. It's always a lot more work than just changing some CSS because you have to consider things like whether you actually want to change every button, what background color the buttons are sat on, what text color it has,…
A better approach that doesn't seem to exist would be some after-the-fact automated cleanup that could at least restructure the class list on attributes to e.g. sort class names alphabetically, replace where you copied text-blue-* instead of text-primary-* to fix issues like that, or other tools to aid refactoring.
Re: Show HN: Tailwind Template Directory
#44Earlier quoted context omitted.
Interesting response. I'm in this war against build steps. Is there a way to 80/20 Tailwind without the build steps? I mean, get 80% of the benefits with 20% of the work.
Yes, CSS variables. Defining a preset of variables on :root for sizes and color ranges goes a long way. The design philosophies behind Tailwind are sound, but like so many I dislike the technical implementation. I feel like there is a lot of halo effect happening with Tailwind where judgement of technical merits is influenced by judgement on visual merits.
Re: Show HN: Tailwind Template Directory
#45Earlier quoted context omitted.
A few points on that. First, in 25 years of front end dev at scale I can't think of a time when a site I've worked on has ever actually made a site wide change to the styling without it being a big deal. It's always a lot more work than just changing some CSS because you have to consider things like whether you actually want to change every button, what background color the buttons are sat on, what text color it has,…
There are solutions of course. But they quickly break down when you're iterating quickly, copying in code from libraries like flowbite, etc and want to go back and restyle later. A better approach that doesn't seem to exist would be some after-the-fact automated cleanup that could at least restructure the class list on attributes to e.g. sort class names alphabetically, replace where you copied text-blue-* instead of…
Re: Show HN: Tailwind Template Directory
#46A 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.
Re: Show HN: Tailwind Template Directory
#47Earlier quoted context omitted.
If you can’t follow a DOM tree through some custom components to debug uhhhh… maybe practice more.
The point was, obviously, that the styling string doesn't go away if you hide it inside an element.
Re: Show HN: Tailwind Template Directory
#48I really was hoping that tailwind was a fad which died but like everything JavaScript it's here to stay sadly I recently found myself staring at a button element with more classes than I have ever seen like Click me! . It’s like the eccentric artist who insists on using every color in the palette. After been forced to use it for almost 2 years I still don't see the point. Your HTML files? Bloated. Your sanity? Questi…
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.
Re: Show HN: Tailwind Template Directory
#49Earlier 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.
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.
(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
Re: Show HN: Tailwind Template Directory
#50Earlier 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.
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.