[ComiCSS] Benefits of Tailwind
-
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.
-
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.
wrote on last edited by [email protected]How *some JS UI libraries handle scoped CSS. Vue for example uses
data-attributes instead. -
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)
imo there’s VERY little difference to a lot of tailwind and style=“…”. you gain a few minor abstractions, but you lose so much
-
https://lemmy.zip/comment/19872383
Usability by third-parties. A webpage is not a pdf.
That's not accessibility.
-
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.
you need to know css to use tailwind because it’s basically style= on everything: it’s css with extra steps
-
Now it is remembering tags for property instead.
Except that you learn the class names once and re-use them across all your projects, whereas CSS classes are different for every single project.
-
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]Working on hobby or shorter lived projects makes all your points agreeable. My work is generally on enterprise SaaS software with vast lifecycle and my thinking is
separate css files
module.css with imported classes: my go to outside of tailwind
These are the same thing, unless it's not configured correctly.
inline styles
Only makes sense for something computed. Like a color computed based on a user selection. Otherwise it should be a class
scss
On a well-maintained project SCSS should be second nature. Something like a Vue single-file component project with scss will certainly not add to the bloat. You'd just have extra lines of vanilla css to scope classes and children selection/scoping that scss does with better syntax, in addition to scss functions and the like. Note that CSS is improving to do the work that SCSS has previously done, just as JS is improving to do the work natively that frameworks, libraries, and toolkits have previously done.
bootstrap
Yeah bootstrap, like jQuery, had it's time. It's largely been replaced by native tooling that shouldn't require external libraries. There's plenty of CSS libraries that are purely for theming, which is mostly what people used bootstrap for. (Smart defaults, basic component and typography themes, etc).
To me tailwind makes sense for setting up projects quickly, but gets out of hand when it comes to customization on a larger scale. You eventually end up with overrides to tailwind's default styles that become hard to manage, outside of the scope of their theming implementation, and then ironically you're usually just using CSS variables which is back to the core toolkit.
-
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)
I'm saying we weren't taught when react was the way people wrote sites. if I was writing a site with pure html, css is great, especially modern css.
but if I'm already using react and their abstractions, opinions on that part aside, I'd personally rather lean on the react component as the unit of reuse. tailwind removes the abstraction that you don't need, since many people in react tend towards one scoped css file per component with classes for each element anyway
at this point I'd be more inclined to say for many sites the api and data fetching things are the content and html+css is presentation. csszengarden is cool but I haven't seen the html/css split help an end user, or really even me as a developer.
-
imo there’s VERY little difference to a lot of tailwind and style=“…”. you gain a few minor abstractions, but you lose so much
Yep. The syntax is slightly cleaner to read probably, but that's about it.
-
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)
You're not wrong.
Realistically, there's a bit of a nuance. Many modern web apps have different components that aren't HTML. You don't need HTML for a component. And those non-HTML components can provide the consistency they need. Sometimes, that's consistency for how to get the data. Sometimes, that's consistency for how to display the data. For displaying, each component basically has its own CSS, but it doesn't need to. A CSS class isn't required.
Tailwind isn't meant to be a component system, It's meant to supplement one. If you're writing CSS's components, it looks horrible. If you're writing components at CSS that needs a foundation of best practices, it works pretty decent. They're still consistency. They're still components. They're just not centered around HTML/CSS anymore. It doesn't have to be.
Sematically, it is still worse HTML. Realistically, it's often faster to iterate on, easier to avoid breakage: especially as the project becomes larger. Combine that with the code being more easily copied and pasted. It can be a tough combo to beat. It's probably just a stepping stone to whatever's next.
-
Tailwind is sooo great, made me extremely productive when scaffolding layouts and managing my palettes.
I really love it
-
I'm saying we weren't taught when react was the way people wrote sites. if I was writing a site with pure html, css is great, especially modern css.
but if I'm already using react and their abstractions, opinions on that part aside, I'd personally rather lean on the react component as the unit of reuse. tailwind removes the abstraction that you don't need, since many people in react tend towards one scoped css file per component with classes for each element anyway
at this point I'd be more inclined to say for many sites the api and data fetching things are the content and html+css is presentation. csszengarden is cool but I haven't seen the html/css split help an end user, or really even me as a developer.
wrote on last edited by [email protected]tailwind removes the abstraction that you don’t need, since many people in react tend towards one scoped css file per component with classes for each element anyway
What abstraction does it remove? In my view, it just adds slightly different abstractions. Instead of knowing an element has a clean block of rules with set meanings, you get a long (potentially grossly formatted/ordered) string of class names that mean the same thing as the CSS properties for the most part, but you've gotta learn a new set of aliases for them. If I am working on someone else's component, one of these scenarios is way easier for me than the other. Even when I worked with TW for a while, I never could really remember a lot of those class names.
csszengarden is cool but I haven’t seen the html/css split help an end user, or really even me as a developer.
You may have never refactored or reskinned a site. I have several times. The hardest projects like that were when content and presentation were tightly coupled. Those felt like pulling teeth to get done.
important!every time a dev buried a style tag somewhere deep in some (for all intents and purposes) unchangeable Java code... shudder When they were loosely coupled, it was fun and went much easier.edit: respect for knowing csszengarden. That site honestly was the first time I learned this principal and saw it applied. I've themed several websites over the years so I've used the concept myself.
-
You're not wrong.
Realistically, there's a bit of a nuance. Many modern web apps have different components that aren't HTML. You don't need HTML for a component. And those non-HTML components can provide the consistency they need. Sometimes, that's consistency for how to get the data. Sometimes, that's consistency for how to display the data. For displaying, each component basically has its own CSS, but it doesn't need to. A CSS class isn't required.
Tailwind isn't meant to be a component system, It's meant to supplement one. If you're writing CSS's components, it looks horrible. If you're writing components at CSS that needs a foundation of best practices, it works pretty decent. They're still consistency. They're still components. They're just not centered around HTML/CSS anymore. It doesn't have to be.
Sematically, it is still worse HTML. Realistically, it's often faster to iterate on, easier to avoid breakage: especially as the project becomes larger. Combine that with the code being more easily copied and pasted. It can be a tough combo to beat. It's probably just a stepping stone to whatever's next.
Many modern web apps have different components that aren’t HTML
What do you mean by this? Web Components?
I am not sure I understand the second paragraph either. I get that if you're doing things well, TW class names can be applied in a non-insane way. Still rubs me the wrong way as a concept though.
