[ComiCSS] Benefits of Tailwind
-
Fair enough. What ui framework(s?) on tailwind do you like?
shadcn is the primary one for react at least. they've done a great job filling the space where you're trying to build up a design system but don't want to start from scratch, but they're great if you just want prebuilt components too
all the components build on something else like radix, and are pretty simple themselves. normally just the radix component with styles. Installing a component just copypastes the source into your project at configured locations.
if you've ever fought against something like mui to get it to fit design changes or change specific behavior, shadcn is great. at some point the extension points of a library aren't enough, but if you own all the code that'll never be a problem.
-
Ngl I love tailwind, I've been through so many different css paradigms
- separate css files: why did we ever do this, if you've ever used kendo's css stuff you'll understand how unfathomable hundreds of thousands of lines of css with complex rules is. Identifying all the things that affect a single component is the work of dozens of minutes at minimum, sometimes hours, you have to understand every nook and cranny of the css spec.
- inline styles: fine, but verbose and requires object spreading, harder to compose, theming is tough and requires discipline to be consistent in your theme conventions, almost impossible to also theme imported library components
- module.css with imported classes: my go to outside of tailwind
- scss: I actually really like scss but it exacerbates the complexity and mystery of css, great for small projects but terrible as projects bloat
- bootstrap: basically just worse tailwind, providing only components and colors
That's all I can think of right now, but tailwind is my preferred way to style a new project, I love how easy theming and style consistency is
wrote on last edited by [email protected]I've never quite understood how adding all these HTML classes to a page is supposed to be clean. Just do a decent job of organizing your code and it's honestly not that hard to keep from breaking styles unexpectedly. This is the part you tell me "well that only works for small projects". Not really, it works when styles are managed carefully. I've worked on fairly large sites with what modern standards would call "bad" css practices and it was fine, we just had an understanding that some devs were frontend (I was lead for a couple years at this particular company I'm thinking of) and some were backend. The backend people botched styles every time so we forbade them eventually. I think that contextless type of "help" is where people get the idea that you have to have a css setup that prevents people from breaking anything unexpectedly. CSS just gets no respect. You wouldn't let a frontend guy go changing your core backend code so why is the reverse ok?
I like css modules too but I totally disagree that css is irreparably broken and needs some system that discourages the cascade of styles in all cases.
-
At first it seems nice...I played with it for a few hours in an established project and didn't mind. But the I thought about using it from scratch and I'm just baffled anyone does. It's like if CSS was slightly more abbreviated but you couldn't use classes so every style has to be specified on every component.
instead of using classes you just use whatever your ui library provides for reuse. stick a classname string in a variable and you have a class. use a component and it just contains all its styles.
unless you mean that if you look in the inspector you see a mess of classnames. I don't have a solution there
-
How are class names relevant for accessibility?
They might mean class names can't help screen readers parse meaning, whereas using the correct tag can?
-
Genuine question : what's wrong with modern vanilla CSS3 ?
Maybe it's because I've used css2 I don't see the point of css frameworks.
People fear what seems foreign. Devs want css to be like a programming language and it's not so they're uncomfortable. Or at least this is my unvarnished opinion
-
Ngl I love tailwind, I've been through so many different css paradigms
- separate css files: why did we ever do this, if you've ever used kendo's css stuff you'll understand how unfathomable hundreds of thousands of lines of css with complex rules is. Identifying all the things that affect a single component is the work of dozens of minutes at minimum, sometimes hours, you have to understand every nook and cranny of the css spec.
- inline styles: fine, but verbose and requires object spreading, harder to compose, theming is tough and requires discipline to be consistent in your theme conventions, almost impossible to also theme imported library components
- module.css with imported classes: my go to outside of tailwind
- scss: I actually really like scss but it exacerbates the complexity and mystery of css, great for small projects but terrible as projects bloat
- bootstrap: basically just worse tailwind, providing only components and colors
That's all I can think of right now, but tailwind is my preferred way to style a new project, I love how easy theming and style consistency is
Honestly, I'm still very much in the "classes define what a tag represents, CSS defines how it looks" camp. While the old semantic web was never truly feasible, assigning semantic meaning to a page's structure very much is. A well-designed layout won't create too much trouble and allows for fairly easy consistency without constant repetition.
Inline styles are essentially tag soup. They work like a print designer thinks: This element has a margin on the right. Why does it have that margin? Who cares, I just want a margin here. That's acceptable if all you build are one-off pages but requires manual bookkeeping for sitewide consistency. It also bloats pages and while I'm aware that modern web design assumes unmetered connections with infinite bandwidth and mobile devices with infinitely big batteries, I'm oldschool enough to consider it rude to waste the user's resources like that. I also consider it hard to maintain so I'd only use it for throwaway pages that never need to be maintained.
CSS frameworks are like inline styles but with the styles moved to classes and with some default styling provided. They're not comically bad like inline styles but still not great. A class like
gap-2
still carries no structural meaning, still doesn't create a reusable component, and barely saves any bandwidth over inline CSS since it's usually accompanied by several other classes. At least some frameworks can strip out unused framework code to help with the latter.I don't use SCSS much (most of its best functionality being covered by vanilla CSS these days) but it might actually be useful to bridge the gap between semantically useful CSS classes and prefabricated framework styles: Just fill your semantic classes entirely with
@include
statements. And even SCSS won't be needed once native mixins are finished and reach mainstream adoption.Note: All of this assumes static pages. JS-driven animations will usually need inline styles, of course.
-
Tailwind is for people that don't know how to use CSS properly. There, I said it.
And they hated him because he was right.
-
In my personal projects, I don’t use anything. I wrote a set of utilities and functions in SCSS years ago that let me easily create reusable variables and classes that already do what TW does, but with less bloat and overhead. I get project-specific spacing, colors, font classes, everything.
I also highly recommend picking up Andy Bell’s Complete CSS course.
-
except we generally use higher level abstractions now, like component based frameworks. If you're writing raw html with tailwind and no library you're doing it wrong and css is a better fit.
well written straight css ends up building it's own tree of components. if you're using react too you're either only selecting a single component (inline styles but have to open two files) or writing good css (duplicating the component hierarchy in css).
tailwind is just the former but better since it encourages using a projectwide set of specific sizes/colors/breakpoints and small scope, the two actual problems with inline styles after organization and resuse, which react etc solves.
I cannot tell if you're saying tailwind is taking away from useful abstractions or adding to them. I think it's taking away from them. A whole bunch of class names in the page is opposite to what we were taught and there was a good reason for the lesson: content and presentation should be defined separately. This lends flexibility, readability and accessibility. Tailwind doesn't help with anything but preventing a breakage in another component/page. To me the reason to value this trade off is that you don't want devs to "have to care about css" which is a bad sign to begin with. It says "we think the way the web is built is bullshit, so let's just try to work around that with the latest attempt to make it better". The web is not bullshit. CSS is beautiful. Embrace the challenge. (Sorry I'm only halfway directing this rant at you)
-
Tailwind is for people that don't know how to use CSS properly. There, I said it.
This is the correct answer. Pig-headed arrogance is why this cancer of a framework exists.
-
Tailwind is for people that don't know how to use CSS properly. There, I said it.
That's a common misconception by people who never used it. The truth is you need to know CSS to use Tailwind. Just because it simplifies styling doesn't mean it simplifies the underlying technology.
-
Which CSS framework is it that puts this shit everywhere?
That one can die in a fire.
-
I've used raw CSS for the last 2 years at work and it's not like it's magically better or my productivity is higher or that it is simpler to read and understand.
Use the tool that works for you, tailwind is fine.
-
Having never used it before, is it that bad?
It's actually very useful. All these negative comments have the hallmarks of people who don't generally use it. I can tell because the criticisms stem from a lack of familiarity, missing the point.
-
Why Tailwind if you have CSS variables?
Tailwind uses css variables, it's really nothing more than a bunch of helper classes on top of css, it's not a replacement or anything.
-
Tailwind is for people that don't know how to use CSS properly. There, I said it.
wrote on last edited by [email protected]It shocks me to see how many programmers think such framework decisions are one-size-fits-all and jump to conclusion that such framework adoption decisions are is due to lack of skillset and experience.
There are many factors at play. You have time to build and maintain your own utility framework, please go ahead.
Two years ago, I led a team which developed a web app that generated 600 million impressions per year. We used Tailwind because we were a small team and I'd rather have my developers work on high value tasks and not maintain a style framework.
If you are an aspiring developer, know this: There are always trade-offs. Not writing pure CSS does not make you a bad developer. Not knowing system design does.
-
Which CSS framework is it that puts this shit everywhere?
That one can die in a fire.
I'm honestly not sure, but I'm fairly certain it's intentional obfuscation done for the production build. Why they think it's so important to hide class names, I'll never know.
-
Which CSS framework is it that puts this shit everywhere?
That one can die in a fire.
fun fact: This isn’t any one specific CSS framework's doing but rather part of how JS UI libraries handle scoped CSS. When you have for example two components that have similar CSS, like one component sets button to color green, another component sets button to blue, then the compiler does this kinda thing because "real" CSS doesn’t support scoping.
So in the above example you'd get button class abcd and button class bcde.
-
I'm honestly not sure, but I'm fairly certain it's intentional obfuscation done for the production build. Why they think it's so important to hide class names, I'll never know.
To fight ad blockers
-
How are class names relevant for accessibility?
wrote on last edited by [email protected]https://lemmy.zip/comment/19872383
Usability by third-parties. A webpage is not a pdf.