3 ms·
No, they're much worse. Lament for the folks that have to maintain that stuff for years after it saved you 30 seconds of dev time.
by ramesh31 3y ago
No, they're much worse. Lament for the folks that have to maintain that stuff for years after it saved you 30 seconds of dev time.
- city41 3y agoI know we're just going to have to agree to disagree, but I find utility class based projects easier to maintain. Coming back to -- or inheriting -- css soup is never fun.
- quickthrower2 3y agoI think people compare the best possible CSS with Tailwind rather than comparing what actually gets done with actual Tailwind.
- deleted 3y ago[deleted]
- ramesh31 3y ago> I think people compare the best possible CSS with Tailwind rather than comparing what actually gets done with actual Tailwind. Yep. The one Tailwind guy on the team will set everything up perfectly, and then no one else will ever have any desire to ever learn Tailwind, and it descends into a complete mess. You can say "just learn Tailwind!", and see how far that gets you with a group of backend devs who've inherited some UI and just need to add a button.
- 1shooner 3y agoRegardless of how easy devs find it to be now, there's no denying that utility-only CSS is fighting the platform it's built on. jQuery and SASS showed the way for their specs to build toward. Contrast that to utility-only CSS, which I suspect is just going to get left behind as CSS solves the problems Tailwind, et al. try to work around.
- naasking 3y agoOn the contrary, utility classes actually drive you to HTML components/composing HTML fragments for HTML reuse, thus eliminating duplicate markup. This is a big problem that CSS, SASS, etc. are not solving and probably can't solve.
- hmeh 3y agoInstead of letting our tools lead us by the nose, what if we let design principles lead us? Why would a styling tool lead me to model my markup? That's the complete inverse of how one should be thinking about it. You model the markup first, you create reusable bits if you need them first. Then you style them. If the CSS forces your hand to change the markup, then you must, but that's becoming more and more rare with modern CSS. I have no doubt that people that don't know the fundamentals at play have an easier time with Tailwind. That's how it goes with hacks. They're usually easier to apply than proper design and implementation. We're throwing in the towel with Tailwind, plain and simple.
- naasking 3y ago> You model the markup first, you create reusable bits if you need them first. Agreed, and with Tailwind you never have to leave this fragment of markup you're designing. You don't have to switch files to add CSS and invent meaningful names for styles, then ensure you use the same name in the markup file, nor do you ever have to hunt down and change these names and the markup across multiple files to ensure they are applied consistently down the road of you're using HTML components. In fact, you rarely have to write CSS at all, you just focus on the markup and sprinkle in the predefined styles that you need. Much simpler. > We're throwing in the towel with Tailwind, plain and simple. If by throwing in the towel, you mean we're acknowledging that they took a suboptimal design path, I agree. Transclusion of HTML fragments would have been a much better path to take, and some people were arguing for it even back then (Xanadu folks IIRC). Now we've come full circle, and people are still arguing that decomposition for reuse are not good ways of structuring dynamically changing and evolving content.
- CuriouslyC 3y agoUtility classes give you the immediacy and power of inline styles in a consistent and controllable way, and they're a natural bridge to class based styling. If you've had a bad experience with utility classes, that's because you've had to deal with bad codebases that use them, rather than due to inherent issues.
- 000ooo000 3y agoSounds a lot like the classic "Hate Agile? You just haven't done it properly" rhetoric
- CuriouslyC 3y agoMaybe, if the normal "agile" definition was limited to just stories and a sprint structure of some kind - atomic user stories and short, feature centric development cycles are hard to argue against. If your intention is to liken Tailwind to SuperMegaScrumKanbanJujitsuMarketingCoderStyle agile, I can assure that there is no real similarity.
- 000ooo000 3y agoMy comment has more to do with the No True Scotsman fallacy than it does with Agile
- sensanaty 3y agoI've worked with Tailwind in 3 separate, huge projects, and it's infinitely easier to upkeep than the monstrosity that large SCSS/CSS codebases turn into. There's no hunting down random css classes all over the codebase, no dealing with insane cascade issues, no idiotic specificity issues, no unused classes that everyone is afraid to touch because it might break some random div somewhere...
- pier25 3y agoYou can still write component-based CSS/SCSS without Tailwind and that solves all problems you mentioned
- joshuaturner 3y agoCSS/SCSS modules are still, for me, the best option to balance maintainability and flexibility within a component
- hmeh 3y agoHave you ever tried making your SCSS/CSS codebases not a huge monstrosity? It can be done.
- CipherThrowaway 3y agoI find this criticism interesting. Among the people actually doing it, it seems to be a near universal experience that Tailwind projects are easier to maintain than class based CSS. What is it about Tailwind that is unmaintainable, in your view?