Play with TailwindCSS in the Browser • Hacker News Board

Re: Play with TailwindCSS in the Browser

#171

Post by aaronbrethorst » Fri, Jun 10, 2022, 4:04 PM UTC

Vinnl wrote: post #146

65 wrote: post #80

I used to be a Tailwind hater. I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file. If you're on the fence, try it out. I think it's the future…

If you're using a component-based architecture (e.g. when using React, Vue or Angular), otherwise it can get pretty annoying. But if you do, it's pretty great; you don't really need the abstraction of reusable classes, when you already have reusable components, and getting rid of useless abstractions makes me a happy programmer.

This isn't meant as a contradiction of your point, but there are plenty of ways to use component-based architectures with server-side rendered apps, too, like GitHub's ViewComponent gem for Rails. https://viewcomponent.org

Also, I'd go so far as to say that if you're not using a component based architecture for your web app's view layer, you're creating a ton of extra work for yourself.

Re: Play with TailwindCSS in the Browser

#172

Post by criswell » Fri, Jun 10, 2022, 4:05 PM UTC

My90thaccount wrote: post #55

jonwinstanley wrote: post #41

Earlier quoted context omitted.

How does it affect quality?

Tailwind means making your HTML non-semantic, usually backed by JavaScript. This has created an arms race where parsers such as screen readers need to do ever-evolving heuristics to provide a reader mode. The code usually cannot be modified or even viewed in a readable form by users. Of all things, it's not user-centric. You're going to tell me next that you have a JSON interface instead. But that's a site-specific A…

Looking forward to the takes on your 91st account.

Re: Play with TailwindCSS in the Browser

#173

Post by timdorr » Fri, Jun 10, 2022, 4:05 PM UTC

LouisSayers wrote: post #120

andiareso wrote: post #81

Earlier quoted context omitted.

But this isn't much different than: extends I'd argue you have less markup to write overall if you are modularizing component logic/styling

And what about your :hover, ::before etc, where do you put those? (genuinely curious)

Those have utility classes: https://tailwindcss.com/docs/hover-focus-and-other-states

Re: Play with TailwindCSS in the Browser

#174

Post by anthonylee » Fri, Jun 10, 2022, 4:05 PM UTC

65 wrote: post #80

I used to be a Tailwind hater. I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file. If you're on the fence, try it out. I think it's the future…

I tried it out last year. Absolutely love it.

Re: Play with TailwindCSS in the Browser

#175

Post by seek » Fri, Jun 10, 2022, 4:05 PM UTC

LouisSayers wrote: post #120

andiareso wrote: post #81

Earlier quoted context omitted.

But this isn't much different than: extends I'd argue you have less markup to write overall if you are modularizing component logic/styling

And what about your :hover, ::before etc, where do you put those? (genuinely curious)

Tailwind supports those

https://tailwindcss.com/docs/hover-focus-and-other-states#ho...

https://tailwindcss.com/docs/hover-focus-and-other-states#be...

Re: Play with TailwindCSS in the Browser

#176

Post by MarquesMa » Fri, Jun 10, 2022, 4:07 PM UTC

rco8786 wrote: post #16

Im sorry but I don’t understand how anyone can look at that and think it’s a good way to build UIs. I’m almost certainly in the wrong, considering how popular this library seems to be getting, but holy heck that looks like a tedious mess to work with. It’s like you have to learn every raw CSS selector, and then also learned how it’s represented in Tailwind, and then scatter that all over your markup.

> and then scatter that all over your markup

This is not how you use Tailwind. Back then there was no such concept as component, so people need to write CSS classes to encapsulate and reuse styles.

Now Components are everywhere, and when you write components and CSS classes at the same time, you're non-obviously duplicating structures (Write components, then write classes corresponding that component).

In essence, Tailwind (or styled components and such) makes component mechanic as your single source of abstraction.

Re: Play with TailwindCSS in the Browser

#177

Post by tomtheelder » Fri, Jun 10, 2022, 4:08 PM UTC

dangerface wrote: post #156

onion2k wrote: post #40

Earlier quoted context omitted.

It’s like you have to learn every raw CSS selector, and then also learned how it’s represented in Tailwind, and then scatter that all over your markup. That's exactly what it is. But... you have to do that regardless of what you use for CSS layout. If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remem…

It seems like the main advantage of tailwind is that you don't have to learn how CSS cascading and specificity works, which is a fair advantage as most frontend developers I talk to don't even realise that specificity is a thing. I don't see the advantage over inline style tho. I see abbreviations as a disadvantage as its just as fast to type background as it is bg but background is clearly more intelligible. How do…

Tailwind is actually a lot like inline styles in certain ways. Whether that's a good thing or not depends on your use case. If you are using a component based framework it ends up, IMO, being way better and less complicated to use the abstraction you already have, your components, as your styling abstraction rather than trying to layer a second abstraction (the cascade approach) on top of it.

The biggest advantage over inline styles is that you are constrained. The idea is that you set up the primitives for your application's styling system: which colors are in use, which font weights, all the way to things like which border radii are valid. Your devs can then only use those.

You are correct that theoretically you can modify them to do anything, but in practice I find that people are extremely unlikely to violate the scheme (in ways like you described, adding a border to bg-red).

As for abbreviations? I think that's probably just eye of the beholder. Since you tend to add a lot of these to your HTML it helps it not get too ridiculously out of hand.

I spent years working with more traditional CSS schemes (including my all time least favorite, BEM), and it was pretty consistently a nightmare within the context of component driven applications. For a while now I've worked with tailwind and it feels like a massive step in the right direction.

I think it's one of those things that really doesn't make sense until you try it and feel the difference for yourself.

Re: Play with TailwindCSS in the Browser

#178

Post by fc373745 » Fri, Jun 10, 2022, 4:09 PM UTC

65 wrote: post #80

I used to be a Tailwind hater. I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file. If you're on the fence, try it out. I think it's the future…

I completely disagree.

To fix the css + jsx in one file, just write your styled components at the bottom of your component.

If you ever seen a react component completely riddled with Tailwind, you'll realize how messy and uncoordinated it looks.

Even I would consider switching between two files just to avoid that style of css.

Furthermore the necessity to utilize horizontal scroll because adding 10+ more rules will inevitably break your prettier printWidth rule is, by far, the most annoying aspect of Tailwind.

    absolute inset-0 bg-gradient-to-r from-cyan-400 to-sky-500 shadow-lg transform -skew-y-6 sm:skew-y-0 sm:-rotate-6 sm:rounded-3xl

    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    linear-gradient(45deg, #fff, #000);
    box-shadow: 1px 1px 1px 0 rgb(0 0 0 / 0.05);
    transform: skewY(60deg);
    border-radius: 4px;
    transform: rotate(60deg);

Consider these two snippets, after time of not looking at your css code, do you think 10+ rules on one line is maintainable?

Not even close, ask yourself to change a css property - you would have to iteratively go from left to right until you find it, whereas looking from top down you can immediately catch the css rule you want to find.

Succinct doesn't mean maintainable, and sometimes verbosity does.

Tailwindcss isn't even close to being the future.

Re: Play with TailwindCSS in the Browser

#179

Post by shroompasta » Fri, Jun 10, 2022, 4:16 PM UTC

65 wrote: post #80

I used to be a Tailwind hater. I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file. If you're on the fence, try it out. I think it's the future…

Yeah, I've tried tailwindcss, but having many rules of css on one line isn't even at all legible, nor do I want to use horizontal scrolling.

Re: Play with TailwindCSS in the Browser

#180

Post by tomtheelder » Fri, Jun 10, 2022, 4:16 PM UTC

calvinmorrison wrote: post #163

onion2k wrote: post #40

Earlier quoted context omitted.

It’s like you have to learn every raw CSS selector, and then also learned how it’s represented in Tailwind, and then scatter that all over your markup. That's exactly what it is. But... you have to do that regardless of what you use for CSS layout. If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remem…

> That's exactly what it is. Which is why this is basically reinventing inline styles. With some shorthand. How did we go from removing and to calling it <div class="bold" an improvement?

It's a lot like inline styles. The big advantage is that you create a design language with the helper classes, and then your devs are constrained to use it. No one can add a border radius of 11 if you only have utility classes for 8 and 16, or whatever. Historically you couldn't do that if you were using inline styles.

You could do it with a cascading approach, but if you're building a component based application (this is what Tailwind is really for) then you already have an abstraction for re-usability. Trying to layer another one on top usually results in a really difficult to reason about mess of interlacing components and style classes.

In short it's a way to use an inline-type styling approach, which is suitable for component based apps, without giving up the ability to constrain developers to a limited design language.

There are a TON of other benefits for utility classes over inline, but I think what I described is the biggest one (media queries, pseudo selectors, stylesheet caching for reduced page load, etc.)

> How did we go from removing and to calling it You can still use and if you want to. Adding a utility bold class also works fine.

Permalink View on HN Reply on HN Top