Live data from Hacker News

Play with TailwindCSS in the Browser

play.tailwindcss.com

261–270 of 300 posts

Re: Play with TailwindCSS in the Browser

#261

I cannot believe how anyone can look at the following code below and think that it's maintainable, just for an input box with additional styles for states: How is mushing every single style into a class attribute supposed to help with readability and maintainability? Even if you use `@apply` to reduce the clutter, you are basically venturing back into "vanilla" CSS territory, and which their docs expressly said to av…

in practice you put those in classes

    .example {
      @apply text-base font-normal text-gray-800;
    }
And there you go.

Re: Play with TailwindCSS in the Browser

#263

Earlier quoted context omitted.

> it's the future of writing CSS. Tailwind didn't invent utility classes. We've done this since the '90s. > significantly easier to maintain Disagree totally. Utility classes are good for rapid prototyping. But they clutter your code, mix semantics with presentation, and are a pain in the ass when it comes to code reuse. The cascade part of CSS is, believe it or not, actually useful for code reuse. Need to change a f…

Okay so one huge difference between now and the late 90's is that we have several very popular ways to create "components" of HTML/JS/CSS. From react to liveview it's very popular. This is important because it's much easier to maintain.

We did back then too. In fact we had SSR. It often took the form of CGI, like PHP - which, hate the language all you want, it has a very sane and scalable model.

Re: Play with TailwindCSS in the Browser

#264

There is only two kinds of people. The ones that don't like Tailwind and the ones that have used it. I know it is conceptually "wrong" and a bunch of well crafted CSS classes would be more elegant. In the end it works, works really well and makes collaboration dead simple. Commonly used groups of classes can either be aliased by @apply or used in a (react) component. I used CSS way before Tailwind was a thing and in…

I've tried it. It's hard to get used to. I'm very used to writing CSS using the browser devtools and there doesn't seem to be a tailwind equivalent. It's OK when I use a framework but most sites I make don't need one.

Re: Play with TailwindCSS in the Browser

#265

Earlier quoted context omitted.

> easier to maintain I’m a huge fan but maintaining tailwind projects is actually a huge pain in the ass. I could maybe improve it by factoring out the classes from my html into a separate sheet using @apply when I’m “done” a project, but I don’t, and it defeats the convenience value anyway. The markup is so overwhelming when there’s anything remotely complex. And sometimes components are almost identical but with sl…

> I could maybe improve it by factoring out the classes from my html I do it by refactoring my HTML. By the way, you don’t need webpack to use Tailwind. It works great with lightweight asset handling too. In particular, there’s a stand-alone compiler.

Cool, I'll check it out thank you!

Re: Play with TailwindCSS in the Browser

#266

I cannot believe how anyone can look at the following code below and think that it's maintainable, just for an input box with additional styles for states: How is mushing every single style into a class attribute supposed to help with readability and maintainability? Even if you use `@apply` to reduce the clutter, you are basically venturing back into "vanilla" CSS territory, and which their docs expressly said to av…

I do not see how this is more readable than plain CSS.

I don't think Tailwind's value proposition is "more readable than plain CSS", even though I think it is competitive in that area.

Re: Play with TailwindCSS in the Browser

#267
post #263

Earlier quoted context omitted.

Okay so one huge difference between now and the late 90's is that we have several very popular ways to create "components" of HTML/JS/CSS. From react to liveview it's very popular. This is important because it's much easier to maintain.

We did back then too. In fact we had SSR. It often took the form of CGI, like PHP - which, hate the language all you want, it has a very sane and scalable model.

and bi-directional data flow was done in the form on long polling. this sounds very much like a get off my lawn argument rather than anything rooted in reality of the now.

Re: Play with TailwindCSS in the Browser

#268
post #254

Earlier quoted context omitted.

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 i…

That's the biggest problem with TW IMO. It's much more difficult to scan a list of classes in a single line. With CSS I can quickly scan the declarations from top to bottom until I find the thing I want. Complex nested declarations are also super easy to scan when using SCSS. When you start adding pseudoclasses with TW it becomes a shit show. And it really makes the markup an absolute mess for anything other than tri…

explain to me how this compiles

  .class1 {
    .class2 {
      &:hover {
        font-family: value;
      }

     body.some-thing & {
       color: woooooo;
     }
    }
  }

Re: Play with TailwindCSS in the Browser

#269
post #254

Earlier quoted context omitted.

That's the biggest problem with TW IMO. It's much more difficult to scan a list of classes in a single line. With CSS I can quickly scan the declarations from top to bottom until I find the thing I want. Complex nested declarations are also super easy to scan when using SCSS. When you start adding pseudoclasses with TW it becomes a shit show. And it really makes the markup an absolute mess for anything other than tri…

explain to me how this compiles .class1 { .class2 { &:hover { font-family: value; } body.some-thing & { color: woooooo; } } }

I don't think the example compares. In languages like JS, double, triple or even further nested ternaries are possible. But terser isn't always better because human readability is important. I can easily understood your SASS example because I know SASS, but I'd never write it like that. If I really wanted to add a decedent selector from a body class to .class1, I'd start a new nest on the body tag.

The problem with Tailwind is there's nothing you can do to avoid the much more difficult to scan and understand syntax described above. I personally don't understand why people are drinking this koolaide. I really think this is a fad a lot of people are going to come to regret when they go back to maintain older projects based on it.

Re: Play with TailwindCSS in the Browser

#270
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…

> it's the future of writing CSS. Tailwind didn't invent utility classes. We've done this since the '90s. > significantly easier to maintain Disagree totally. Utility classes are good for rapid prototyping. But they clutter your code, mix semantics with presentation, and are a pain in the ass when it comes to code reuse. The cascade part of CSS is, believe it or not, actually useful for code reuse. Need to change a f…

I’m familiar with the pain point you’re describing. It’s not the cascade, it’s the ability to target a child element through a selector. (Which utility based approaches do away with)

But the thing is you can always do that if it’s needed. There’s no one forcing you to strictly adopt the utility pattern. It’s all just vanilla CSS at the end of the day. If a hybrid approach works best for your project then do that.

Personally I find the need for this to be quite rare, and there are actually some good arguments against writing too much specificity in to your css even if it’s more convenient up front.

Post reply on HN