TailwindCSS v2.0 • Hacker News Board

Re: TailwindCSS v2.0

#461

Post by rglullis » Sat, Nov 21, 2020, 4:03 PM UTC

mercer wrote: post #454

rglullis wrote: post #452

Earlier quoted context omitted.

> you're going to start having issues in targeting these elements unless you only ever have exactly 1 single design for each element, no matter where it is. My example shows precisely how untrue that is. The buttons got different styles without having to change anything in the html structure. > What happens if you put inside different tags? Then you define the corresponding rule. With SASS that is almost too easy. Al…

> Then you define the corresponding rule. With SASS that is almost too easy. Also, don't forget that the C in CSS means cascading. Over the lifetime of projects 'cascading' always led to headaches. There's a reason the whole BEM thing became a thing. > Do you think it will be too repetitve? Make a SASS mixin that defines these for you. Not only you're still keeping CSS separate from the HTML structure, it will very l…

> But why? Other than 'this is the way it has always been and I refuse to change my mind'?

It is interesting how the immediate use-cases dictate our first opinions of the technology.

As I stated in one of the first comments of this thread: I am working on a self-hosted crypto payment gateway and I am providing a "Stripe Checkout" widget for those that want to set up a payment workflow inside their website.

I could do exactly what Stripe does and make one good-looking widget and just give the user the option to change some things like color scheme. But two things go against that: first, I am a terrible designer, so I am sure that anything that I come up with will not be as nice what Stripe does. Second, it is an open source project and I would rather have more people feeling encouraged to contribute their own different themes than trying to enforce "my" styling, which we already established will be bad.

What am going to do, then, if not ensure that I write the components without any predefined styling and perhaps offer an open source repository of "themes" - like CSS Zen Garden?

So, there you have it. My reason to argue for a "pure" HTML structure is not just out of some idealist out-of-touch mentality.

> When someone comes up with a popular style-free standard, assuming that's practically possible and good enough to become popular, I'd happily switch to that.

Honest question: would you pay for funding this? I think this haven't come to be is because it's much easier to sell a "turn-key" system than something that is flexible enough to get other developers to say "I could've done that as well."

Re: TailwindCSS v2.0

#462

Post by StreamBright » Sat, Nov 21, 2020, 6:43 PM UTC

mercer wrote: post #458

StreamBright wrote: post #414

Earlier quoted context omitted.

Sorry for my ignorance, I am a backend developer and I am trying to figure out what is the best for my frontend code (when I work alone on something). So far I was using Tachyons ( https://tachyons.io/ ) and elm-ui ( https://elm-ui.netlify.app/ ). Is there a chance that Tailwind would be better for small / medium sized projects than these? Based on your comment it looks like. The only problem with Tailwind just by lo…

Once I properly used Tailwind for a mid-sized project, I was pretty much sold on it. Size was my main issue. With PurgeCSS the payload can be really small though. it only includes the Tailwind classes that you're actually using.

Thanks! I am going to check out PurgeCSS.

Re: TailwindCSS v2.0

#463

Post by mercer » Sat, Nov 21, 2020, 7:14 PM UTC

rglullis wrote: post #461

mercer wrote: post #454

Earlier quoted context omitted.

> Then you define the corresponding rule. With SASS that is almost too easy. Also, don't forget that the C in CSS means cascading. Over the lifetime of projects 'cascading' always led to headaches. There's a reason the whole BEM thing became a thing. > Do you think it will be too repetitve? Make a SASS mixin that defines these for you. Not only you're still keeping CSS separate from the HTML structure, it will very l…

> But why? Other than 'this is the way it has always been and I refuse to change my mind'? It is interesting how the immediate use-cases dictate our first opinions of the technology. As I stated in one of the first comments of this thread: I am working on a self-hosted crypto payment gateway and I am providing a "Stripe Checkout" widget for those that want to set up a payment workflow inside their website. I could do…

> So, there you have it. My reason to argue for a "pure" HTML structure is not just out of some idealist out-of-touch mentality.

No, but it's based on a use-case that is very specific and considering that it's a relative uncommon one, I don't see the point of trotting it out. Okay, so in this particular situation maybe something like Tailwind isn't ideal. Nobody is arguing that it is.

> Honest question: would you pay for funding this? I think this haven't come to be is because it's much easier to sell a "turn-key" system than something that is flexible enough to get other developers to say "I could've done that as well."

Sure. I mean, I'm close to paying for Tailwind UI, so paying for good stuff is definitely something I'm willing to do.

But I think what you propose doesn't exist not for lack of payment, but because it's just not that easy to do. In lieu of perfection, stuff like Tailwind can be a pretty good improvement over other things. No need to whine about it or compare it to some hypothetical ideal that you deem good enough for your edge-case needs.

Re: TailwindCSS v2.0

#464

Post by manigandham » Sat, Nov 21, 2020, 10:55 PM UTC

rglullis wrote: post #452

manigandham wrote: post #449

Earlier quoted context omitted.

When pages get complicated, you're going to start having issues in targeting these elements unless you only ever have exactly 1 single design for each element, no matter where it is. What happens if you want a different styled buttons? What happens if you put inside different tags or different order? What happens if you need to change a single specifically? The complexity of cascading rules and specificity and HTML s…

> you're going to start having issues in targeting these elements unless you only ever have exactly 1 single design for each element, no matter where it is. My example shows precisely how untrue that is. The buttons got different styles without having to change anything in the html structure. > What happens if you put inside different tags? Then you define the corresponding rule. With SASS that is almost too easy. Al…

If it was so easy then it wouldn't even be a problem. You're arguing for the ideals again. This isn't new, many people have been trying for the past 15 years but there's a reason it just doesn't work out. If you want to find a "paretto-efficient basis for frontend development" then good luck, but reality has shown that CSS is not separate from HTML, they are the same concern because presentation includes structure.

Cascading rules and specifying by HTML layout are hard to deal with, especially in larger projects, because that structure may change and rules can overlap in complex ways. It's far easier to just atomically apply some classes directly to your HTML. And yes, you can use Tailwind as mixins within your sass rules without ever touching the HTML if you want.

Re: TailwindCSS v2.0

#465

Post by rglullis » Sat, Nov 21, 2020, 11:32 PM UTC

mercer wrote: post #463

rglullis wrote: post #461

Earlier quoted context omitted.

> But why? Other than 'this is the way it has always been and I refuse to change my mind'? It is interesting how the immediate use-cases dictate our first opinions of the technology. As I stated in one of the first comments of this thread: I am working on a self-hosted crypto payment gateway and I am providing a "Stripe Checkout" widget for those that want to set up a payment workflow inside their website. I could do…

> So, there you have it. My reason to argue for a "pure" HTML structure is not just out of some idealist out-of-touch mentality. No, but it's based on a use-case that is very specific and considering that it's a relative uncommon one, I don't see the point of trotting it out. Okay, so in this particular situation maybe something like Tailwind isn't ideal. Nobody is arguing that it is. > Honest question: would you pay…

The only issue I am taking with your comment is to think that I am "whining", like I am just waiting for everyone else to respond to my plea. I've done this idea of taking SASS mixins from both materialize.css and Bootstrap already for two different projects and partially for the communick website.

I think it's actually easy to do it. It can be laborious, but not hard. And even the labor is something that can/should be done only once. So the only justification that I can find to not have this as a more widely adopted practice is that using utility classes is "easier" to get started. Coupled with the fact that most people don't care about making their components "portable" between different designs, and we end up with this local maximum.

Re: TailwindCSS v2.0

#466

Post by mercer » Sun, Nov 22, 2020, 8:15 AM UTC

rglullis wrote: post #465

mercer wrote: post #463

Earlier quoted context omitted.

> So, there you have it. My reason to argue for a "pure" HTML structure is not just out of some idealist out-of-touch mentality. No, but it's based on a use-case that is very specific and considering that it's a relative uncommon one, I don't see the point of trotting it out. Okay, so in this particular situation maybe something like Tailwind isn't ideal. Nobody is arguing that it is. > Honest question: would you pay…

The only issue I am taking with your comment is to think that I am "whining", like I am just waiting for everyone else to respond to my plea. I've done this idea of taking SASS mixins from both materialize.css and Bootstrap already for two different projects and partially for the communick website. I think it's actually easy to do it. It can be laborious , but not hard. And even the labor is something that can/should…

The problem in this discussion is that most of us are happy with Tailwind based on our experience using it, and our experience with previous approaches. And not just because it's "easier to get started".

And from what I can tell, most of us do care about portability and componentization.

If your experience is different, then that's interesting, but not much of an argument in itself. Either 1) we're just much worse at this than you are, 2) your use cases and projects are more unusual/uncommon, or 3) what you think is 'easy to do' perhaps is not, and perhaps you'd benefit from a more Tailwind-like approach too.

Obviously if what works for you, that's fine. I don't use Tailwind in all my projects, and in some cases wouldn't even do so if I could. And it's not like what came before is entirely unworkable.

But it feels a bit dismissive to argue that our experiences are just wrong, or that we're just taking the lazy way out.

Re: TailwindCSS v2.0

#467

Post by dikaio » Sun, Nov 22, 2020, 6:46 PM UTC

pembrook wrote: post #431

rvense wrote: post #368

Earlier quoted context omitted.

> It's not like Tailwind is SAP or something. It's just CSS. You shouldn't need to re-work your entire process around it. No, your designers should already be working to scales for size, colour etc. which you can implement in Tailwind. If they don't, now's a good time to start. > How the hell does that help with consistency? You have to copy paste that mess every time you create a new button You're extremely not supp…

> with your JavaScript component framework If I’m using React components, tailwind makes even less sense. I’ve already separated my button large out as a component, guess what happens in a mature design system? The system gets updated and changed to fit the needs of the product. So what happens when you need to change button large in tailwind? You need to restyle the button with the spaghetti mess (maybe add somethin…

In regards to you needing to change your button when the design system needs to change I think you may be thinking about how to apply your current naming conventions or methodology as something like sass for instance what you could do is create the default button component and anything that you think you may need to change about that button you have props with defaults already set this way if you have one button requirements you just include it in the prop of that button, if you need to change all of them then you update the default prop.

In other wards instead of doing you're doing .

Re: TailwindCSS v2.0

#468

Post by bkeating » Sun, Nov 22, 2020, 8:52 PM UTC

Tailwind and utility-first in general is a major win in my book if for one thing only; I don’t have to think about naming my elements at the html level at the start.

Huge speed increase that gives me immediate results. You can absolutely spot and define those names, but you don’t have to think of them up front, allowing you to move forward more abstractly. Readability and maintainability seem like an inefficient nightmare but so far I have felt no pain or burden.

Hats off to the Tailwind team. This is the way.

Re: TailwindCSS v2.0

#469

Post by ivanhoe » Sun, Nov 22, 2020, 11:47 PM UTC

rglullis wrote: post #442

roryokane wrote: post #439

Earlier quoted context omitted.

They mean a normal component in React, Vue, Angular, or whatever other front-end technology you are already working with. I think they’re calling it a “micro-component” just to emphasize that there is no logic in the component beyond the templating.

Ok. So it is basically that going full-on "CSS dictates HTML" approach, which only makes (some) sense if you have full-control of every aspect of the stack and you just want to have a single repository for your design system. Honestly, the only possible place where this may make sense to me is if you have tooling that can keep a two-say sync between designer tools and programmers tools. I think AirBnB was doing somet…

IMHO main issue is that you suffer from the same problem that killed jQuery. By separating html and the logic affecting that html (css in this case, and event handlers for jQuery), you might make it look cleaner, but you also make it much harder to track what is affecting what. You need to scroll up and down to follow what's going on, you might miss that there's say 3 buttons with this class you defined and not just 2, etc. And as the complexity grows, it gets exponentially harder to manage it and it quickly can turn into a mess. Components help keeping the html short, so this approach is certainly working better than with the old monolith pages, but it's still more work to have single .button and then look up its styles, then to have all the utility classes directly on it.

Also on bigger project you're almost guaranteed to have someone on the team who will insist on naming their classes in totally unintuitive way, or you'll end up with .big-blue-button that will at some moment end up red actually because they've been in hurry and forgot to rename the class.

One of the biggest benefits from using the frameworks is the standardization and uniformity, you're guaranteed that everyone on the team now or anytime in the future will know exactly what classes/mixins/variables are available and will have a documentation on how to use them. You need extra people to meet the deadline, you just hire devs who know the framework and you're good to go, no extra onboarding needed to explain where the buttons variables are located, and where to apply which, and how to name their classes, etc.

Re: TailwindCSS v2.0

#470

Post by rglullis » Mon, Nov 23, 2020, 9:37 AM UTC

ivanhoe wrote: post #469

rglullis wrote: post #442

Earlier quoted context omitted.

Ok. So it is basically that going full-on "CSS dictates HTML" approach, which only makes (some) sense if you have full-control of every aspect of the stack and you just want to have a single repository for your design system. Honestly, the only possible place where this may make sense to me is if you have tooling that can keep a two-say sync between designer tools and programmers tools. I think AirBnB was doing somet…

IMHO main issue is that you suffer from the same problem that killed jQuery. By separating html and the logic affecting that html (css in this case, and event handlers for jQuery), you might make it look cleaner, but you also make it much harder to track what is affecting what. You need to scroll up and down to follow what's going on, you might miss that there's say 3 buttons with this class you defined and not just…

Respectfully, I disagree about the comparison with jQuery.

On the technical grounds, you are right that the biggest thing against jQuery was that it operated on the global context and that made large codebases messy, and that CSS alone might lead to a similar experience.

But I am not talking about CSS, I am talking about having an organized SASS framework, which can provide the utility classes (mixins) and which then your code would be organized by "base elements/components/pages" along with variable definitions.

The approach I am using and suggesting does require a certain discipline. It will also require that the whole team conforms to the idea that no class should represent presentation directives. But in my view this discipline not only would be beneficial in the long term, the separation of concerns would improve the chances of making reusable components and design systems that are easier to improve on its own, separate from the specifics of each underlying website/webapp that tries to adopt it.