Any general advice for incorporating Tailwind into a massive legacy project with awful CSS architecture?
Tailwind CSS v3.0
311–320 of 448 posts
Re: Tailwind CSS v3.0
#312Earlier quoted context omitted.
> CSS isn't powerful enough to style HTML however you want without having to add a soup of extra divs and classes that are only there for styling. Can you provide an example? I've never found this to be the case, particularly with modern CSS. Happy to be wrong though.
Just open up the inspector on any major website like Facebook, Twitter, Github, etc. How complex is the UI you typically work with? Once you get to a certain level of complexity, it's literally not possible to not end up with the div soup.
It's definitely possible, but it's not done.
And it's hard to take Facebook serious as an example. They're known to engage in HTML obfuscation on purpose.
https://dev.to/ganderzz/how-facebook-avoids-ad-blockers-4mdc
Re: Tailwind CSS v3.0
#313Earlier quoted context omitted.
To be fair, one of the big perks of Tailwind (IMO) is not having to have a big ol' folder of CSS that you have to figure out what applies where in HTML, but rather just having all your styling inline (while still staying consistent, which is the usual downside of inlining styles manually). Having to have a tailwind-addons.css when you needed random bits of CSS they didn't have classes for kind of sucked; this looks l…
The same reason Vue introduced single-file components! If you haven't tried Vue yet, I strongly recommend it based on what you said.
Thanks for the recommendation! I've mostly been thrust into React, which works for what I need but I definitely don't enjoy it. I'll give Vue a shot!
Re: Tailwind CSS v3.0
#314Every time Tailwind does something great and gets posted here, the conversation devolves into the same arguments: “I don’t get it. It’s just inline styles.” What is it about CSS that gets people so offended and opinionated? If it were a new JS framework, few people would be saying “I just don’t get XYZ. Use React”. Is it because Tailwind is so drastically different and breaks people’s core ideas about separation of c…
When you first hear Tailwind's concepts, they seem to contradict everything you know about good software design. When you try it out and begin to remember some of the class names, you get into a great state of flow - it's the high developers are always chasing. I can't help but feel that Tailwind detractors have never actually tried Tailwind or are too square to give it a chance.
regarding 'contraditing everything you know about good design' i feel this way about designing webpages using elements. the constraint really forces you to be creative with using image elements to make everything fit on the page just right. styling with tables used to be popular, but then it went out of fashion, unfortunately. i'd like to see it make a comeback. i'm not being sarcastic either.
Re: Tailwind CSS v3.0
#315Earlier quoted context omitted.
In the context of component based development, react etc., I believe what you describe is actually very beneficial. Think about a case where instead of doing something you write an atomic component which uses tailwind internally. With this workflow: * There are no global styles that can have an unknown or unexpected impact on the application when modified. * The component's style is completely encapsulated. It can be…
I use Tailwind utility classes extensively to create reusable components in a Rails app using GitHub's ViewComponent gem ( https://viewcomponent.org ) Occasionally, I'll use @apply directives to DRY up something that isn't easy to encapsulate at the component level, but 95% of the time, I can easily get by with utility classes. I try to avoid using hyperbolic-sounding language like 'revolutionized,' but Tailwind + Vi…
Thanks mate! I've been considering this path and may give it a go.
Although, I'm still a bit nervous spitting utility classes all around. That sounds almost like inline CSS and almost unmaintainable.
Re: Tailwind CSS v3.0
#316Before you ask, as it happens in every Tailwind post, what is the point of this when CSS "promotes" reuse and separation of concerns, have a look at @ 5e92cb50239222b comment: https://news.ycombinator.com/item?id=29501650 And let me repeat what every Tailwind fanboy (like me) states every time this project is on HN: don't knock it till you've tried it. Look at the animated example in the front page. You'll never be a…
Any thoughts as to how Tailwind can handle dynamic plugins using Tailwind? Ie it seems Tailwind relies on tree shaking to produce sanely sized CSS. But if you have plugins which rely on Tailwind, you'd have to either ship the full sized Tailwind CSS or they'd have to duplicate CSS and ship with it. So far with this plugin/extension design i've not found a way to use Tailwind and also retain nicely sized CSS.
> it seems Tailwind relies on tree shaking to produce sanely sized CSS
This 3.0 release has its biggest feature be JIT. If you read the linked blog post, CSS is no longer purged but generated dynamically by reading your source files and generating the TW classes you use. It's not tree shooken anymore
Re: Tailwind CSS v3.0
#317Every time Tailwind does something great and gets posted here, the conversation devolves into the same arguments: “I don’t get it. It’s just inline styles.” What is it about CSS that gets people so offended and opinionated? If it were a new JS framework, few people would be saying “I just don’t get XYZ. Use React”. Is it because Tailwind is so drastically different and breaks people’s core ideas about separation of c…
For me, the situation is: I gave tailwind a try. I hated it. I spent a lot of effort of ripping every last tailwind class out of my project.
And yet, a lot of people swear by it and think its great. This really confuses me, and I'd kind of like to understand: how can other people like this thing that I think is terrible?
Re: Tailwind CSS v3.0
#318I've never used Tailwind CSS. I watched the video "Just-In-Time: The Next Generation of Tailwind CSS" and all of it seems like they're solving problems that are entirely of their own creation, and doing so in an impressively complex way.
The use case demonstrated was suppose you have a twitter button on your site, and it has to have a background color of #1da1f2 because that is Twitter's brand color. Instead of writing style="background-color: #1da1f2" like a normal person they have a class name called bg-[#1da1f2], and their "JIT compiler" generates a named class with that property.
In another part of the video, they use className="font-bold" instead of style="font-weight: bold". Apparently the advancement in this version is that instead of having all of those pre-defined classes they only generate the ones you actually use. The feature list for 3.0 includes the ability to use any color you want, and even arbitrary CSS properties that the framework doesn't explicitly know about.
Is this progress? I could use the style attribute in 1999.
Re: Tailwind CSS v3.0
#319I've never used Tailwind CSS. I watched the video "Just-In-Time: The Next Generation of Tailwind CSS" and all of it seems like they're solving problems that are entirely of their own creation, and doing so in an impressively complex way. The use case demonstrated was suppose you have a twitter button on your site, and it has to have a background color of #1da1f2 because that is Twitter's brand color. Instead of writi…
You miss the point. Using the style attribute everywhere causes duplication; using css classes can quickly lead to bloat where you have lots of unused classes.
This is a way of paying only for what you actually use.
Re: Tailwind CSS v3.0
#320Earlier quoted context omitted.
> I used the JIT version recently on a new landing page Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability. Where it gets less fun is when you want widget consistency across multiple areas of a site and across design tweaks over time, since now you have to deal with…
In the context of component based development, react etc., I believe what you describe is actually very beneficial. Think about a case where instead of doing something you write an atomic component which uses tailwind internally. With this workflow: * There are no global styles that can have an unknown or unexpected impact on the application when modified. * The component's style is completely encapsulated. It can be…
Those benefits seem the same as the benefits of styled components or css modules?