Live data from Hacker News

Play with TailwindCSS in the Browser

play.tailwindcss.com

251–260 of 300 posts

Re: Play with TailwindCSS in the Browser

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

> We've done this since the '90s.

no, we really didn't. tho i'll agree that utility classes have been a thing for longer than tailwind/bootstrap/tachyons/pico/etc have existed

> mix semantics with presentation

there is nothing semantic about class names: nothing, zero, zilch - using IDs are even worse due to specificity, with none of the "semantic" benefit. focus on the correct top level wrappers

part of me wonders about the extent of what HN commenters actually do on the web regarding styles, or if they just slap together some homogenous web app or static site where its rather easy to not have a design team needing flexibility on every little thing.

case in point, our main "button" has about 15 different base variants (that *3 currently) depending on context, not counting the interaction states.

Re: Play with TailwindCSS in the Browser

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

> 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 slight variations. I miss seeing an element with a simple .classname to let me know what’s going on. Admittedly this is due to a lack of foresight on my part but moving forward I’m either re-thinking tailwind or ditching it.

I even have a pre-release 0.6v or something running on a production site I need to maintain. Which is stupid and my fault but demonstrates 1) that I’m a huge fan and have been using it forever and 2) it can suck maintaining if not thought out properly.

Don’t forget now you need to configure webpack for node sass and purge css and blah blah blah.

Tailwind is great for building something you never need to touch again.

Re: Play with TailwindCSS in the Browser

#253
post #105

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 used Tailwind on many projects at work for about a year now. I do not like it. Tailwind seemingly affords an easy way of writing inline styles, but it 1) clutters the HTML, 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that), 3) uses names that can be similar but are not identical to CSS properties and feels like a bad abstracti…

I mainly work in Svelte, and I use tailwind's @apply all the time in my local component.

Mainly I get the benefits from setting the tailwind config file for things that apply across my components.

Not all of my repeatable markup lives as utilities, e.g. and — I define those classes in the scss file. Oh yeah, combining scss and tailwind also gives lots of composability options

Re: Play with TailwindCSS in the Browser

#254
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 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 trivial examples.

People complain about not knowing where the styles are, which was a valid concern when doing old school CSS (everything in a couple of files) but I haven't had that issue since I started using SCSS in almost a decade.

When doing front end with components I store the SCSS for the component in the same directory of the component file. Eg: MyComponent.svelte and MyComponent.scss. Super easy and clear. I've also written a small VSCode extension that allows me switch between the component and its SCSS file with a shortcut. I don't even have to open the SCSS file or look for it. I configure Webpack or whatever I'm using to automatically include the .scss files in the component folders. I have all the convenience and control I want without relying on something as convoluted as TW.

Re: Play with TailwindCSS in the Browser

#257
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 honestly think I'd quit my job if I had to go back to any other system. Not sure what could be next for maintaining / styling, but this is the best I've ever had it.

Re: Play with TailwindCSS in the Browser

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

> Hopefully you're good at that and you can remember, else you'll duplicate things. Hopefully your entire team are aligned on the same naming conventions, or your project's styles will be a total mess. - CSS classes can be named on a per-component basis, according to one of the well-established naming conventions (BEM, SMACSS, or whatever). This does not require remembering the names of other classes. - With the arri…

my thought exactly, sometimes I wonder when reading about tailwind... naming css classes has been a problem exactly 0 times in recent memory...

Re: Play with TailwindCSS in the Browser

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

> 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.

Re: Play with TailwindCSS in the Browser

#260
post #146

Earlier quoted context omitted.

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.

I’d add you don’t even need ViewComponent. Layouts, partials, variants, and helper functions provide plenty of heavy lifting options when it comes to refactoring your HTML.

My take on ViewComponent: it’s what helper functions become when they grow up into proper objects. Great for larger projects, may be more infrastructure than necessary for smaller ones, adopt incrementally when they seem compelling.

Post reply on HN