Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Play with TailwindCSS in the Browser

play.tailwindcss.com

Post reply on HN
Print view View original

211–220 of 300 posts

Re: Play with TailwindCSS in the Browser

#211

Post by mooktakim »

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…

It's really for the React generation. People used to embedding the code, markup and style all in one file.

I've tried multiple times to use it, but I always end up using something like bootstrap. Funnily enough, I paid for tailwindui and take the styles and reproduce them in bootstrap css.

Bootstrap community seems to have given up. They only want to sell templates. The default is ugly. Sometimes I think about going back to bootstrap 2.

Re: Play with TailwindCSS in the Browser

#212

Post by aidos »

shroompasta wrote: post #206
aidos wrote: post #190

Earlier quoted context omitted.

You can do both of those things with Tailwind. Put the css only components at the bottom and use them in your main component if you want. Break the classes over multiple lines if you want. The difference between your 2 examples is that TW allowed you to handle media queries seamlessly but you couldn't do that in your styles example.

i'm not sure what you mean by 'seamlessly' but a media query in styled components would just be @media (max-width: 700px) { css here } it's not that much harder. Also, the lack of address of real problems of tailwindcss of OPs comment in terms of mantainability is something you consider. reading iteratively from left to right especially if it has 10+ css rules, in terms of legibility, is not really all too great. I w…

"Also, the lack of address of real problems of tailwindcss of OPs comment in terms of mantainability is something you consider."

Not sure what you mean by that. I've been doing this since we did layouts with tables and shims in the 90s. I've found TW pretty nice to maintain myself.

"It's not that much harder", but a) it's a simple example and b) now you're going to litter your code with a load of hard coded media widths?

Let's talk about something concrete. Let's take a really simple layout that changes border and margin responsively (this, for me, is seamless).

    
      
        Content
How would you do that?

Re: Play with TailwindCSS in the Browser

#213

Post by jmoreno94 »

shroompasta wrote: post #206
aidos wrote: post #190

Earlier quoted context omitted.

You can do both of those things with Tailwind. Put the css only components at the bottom and use them in your main component if you want. Break the classes over multiple lines if you want. The difference between your 2 examples is that TW allowed you to handle media queries seamlessly but you couldn't do that in your styles example.

i'm not sure what you mean by 'seamlessly' but a media query in styled components would just be @media (max-width: 700px) { css here } it's not that much harder. Also, the lack of address of real problems of tailwindcss of OPs comment in terms of mantainability is something you consider. reading iteratively from left to right especially if it has 10+ css rules, in terms of legibility, is not really all too great. I w…

Your eye gets trained eventually. Also most of our components look something like this once class names start to get long.

  const inputWrapperClass = classNames(
    'flex flex-col gap-y-1',
    'group-focus:border-blue-500',
    isDisabled ? 'opacity-50' : null
  );

  return (
    
    {...}
    
  )
In practice our "full-stack" developers are writing less and less CSS because they're just using the components that encapsulate all of this, our frontend developers get code completion for our design system tokens, and we haven't had to ship any new CSS classes in the last few months.

Our new hires are able to just use the design system tokens rather than going in and saying `padding: 5px` and `padding: 4px` because the designer didn't think it was a big deal. They just write `p-1` and that covers it.

All the components get tree-shaken and only ship the styles they need so bundle size gets reduced as well.

If I had my dream team of 10x frontend developers and a perfect design team who always follows the rules they create then yes I would use regular css with css variables, but I don't.

I am more than happy to sacrifice "separation of technologies" for a happier team, more consistent styling, and faster delivery times.

Re: Play with TailwindCSS in the Browser

#214

Post by vsroy »

People here are complaining about how Tailwind is annoying because the className strings are too long. The correct solution is to write a quick 1-file helper.

See: https://gist.github.com/vedantroy/80fb2feb21b07b6f53032b8725...

I wrote that. It allows me to do stuff like:

    const Button = tw.div(`
        bg-blue-500
        rounded
    `)
Any complaint about how tailwind forces overly long class names should probably look at this comment first.

Re: Play with TailwindCSS in the Browser

#215

Post by majkinetor »

shroompasta wrote: post #207
majkinetor wrote: post #204

Earlier quoted context omitted.

You seem to miss the bigger point - Tailwind constraint your css use so that you don't imagine stuff in ad-hoc manner. And you can split, and sort classes with editor plugins which makes it almost equally good as your example.

i think you missed his point to be honest. Regardless of where place your tailwindcss or where you split / sort classes, reading iteratively from left to right, especially if the css rules are numerous, is not legible. just looking at the two examples above, and already I can tell how much it would be easier to maintain verbose css.

So u cant manage the little bigger list of words? And you can manage way complex software behavior at the same time? Particularly if it lets you manage small subset of CSS ?

Re: Play with TailwindCSS in the Browser

#216

Post by deckard1 »

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…

> 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 font deep in some nested component? Not a problem with CSS. Tailwind, you're fucked. You'll need to modify each component layer to pass down a class prop. Or do some ugly context hack.

Re: Play with TailwindCSS in the Browser

#217

Post by Rapzid »

ramesh31 wrote: post #147
lolinder wrote: post #125

Earlier quoted context omitted.

Color management is easy in SCSS, too, though. I just have a _colors.scss file and enforce that no color is ever used that isn't in that file. If I'm working with a designer rather than designing my own UIs, that they have a default color palette isn't helpful, so what do I gain from Tailwind? EDIT: Reading some other comments, I wonder if part of the reason I don't see the utility is that I use Vue, not React. It so…

The killer for SASS nowadays is CI. You're either using the (ancient, slow) Ruby implementation of SASS, or node-sass which requires a native binary build and causes headaches across environments. Furthermore, with Post-CSS, the feature set of SASS has been completely subsumed by the latest CSS standard. There's really no good reason to use it anymore.

For large apps yes; all Sass compile options are slow with embedded Sass being the least slow BUT:

Does your tooling even support embedded Sass?! Vite does not. Our version of webpack does not.. The Cenobites would LOVE Sass; never ending performance pain.

Re: Play with TailwindCSS in the Browser

#218

Post by cgarvis »

aaronbrethorst wrote: post #171
Vinnl wrote: 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.

+1 Using it in a Elixir/Liveview app. Using phx_component_helper has made making those components really easy. https://phx-component-helpers-demo.onrender.com

Re: Play with TailwindCSS in the Browser

#219

Post by jozzy-james »

tomtheelder wrote: post #188
xkcd1963 wrote: post #139

I tried it out for a project and I regret it. Following reasoning: - CSS was created so no inline styling would be necessary. By assigning CSS attributes to classes we are back at inline styling. The html just explodes if you don't put the tailwind classes somewhere else, but then again, CSS is already here for that - one wastes time learning new naming conventions. Most frontend developers have internalised CSS attr…

I think there's a chance that you're using it in a project it isn't suited to. For your first reason, component driven applications provide a compelling reason to go "back" to inline styling. You already have your abstraction, and adding another one (cascading styles) does you no favors. It just creates two interleaving re-usability schemes that are a nightmare to maintain in parallel. This is the same reason that co…

it isn't really _designed_ for JS based applications, but if you're not at least running vite/webpack/etc with PurgeCSS then your builds will be rather bloated and you lose out on customizing the settings - if you really just don't care, then you can run the default CDN build

Re: Play with TailwindCSS in the Browser

#220

Post by jozzy-james »

jbaczuk wrote: post #134

I've found Tailwind to be great for getting a project going quickly. It's pleasant to use when you get started, but it can become a pain later on when you have a lot of styles to maintain. I've been using it everyday at work for a year and a half, and wished I would have known a few things before I started using it. Here are a few: 1 - It encourages styling on the fly. Because it is faster initially, you don't have t…

1. Being able to run a dev build (with no PurgeCSS) and use the .cls area of dev tools to quickly throw together TW classes to get stuff sorted, then carry over to the final resting place is wonderful. Compared to manually typing each property and value on the element and then copypasta'ing from there.

2. If you need to use the same group of utility classes over and over, extract to a class - either with @apply (if you want to keep the flexibility of config updates) or vanilla.

3. I'm not sure I'm following here - if you're changing the value of a tailwind class, you should do that via the config

4. I've found the naming differences easy enough to follow - line-height vs leading makes sense if you come from a design background. I think the biggest gotcha I had early on was everything is mobile first by default - so sm:* is actually _larger_ than the default.

5. the JIT is a wonderful addition, but does come with overhead currently - so that's why it (i assume) isn't just the default way of doing things.

6. not a problem i've run across, but why would a component config supersede an app config?

to your last point, we use tailwind in conjunction with a fair amount of legacy sass to do what we need (many small nuances, spread across 4 different sites, that are otherwise the same) - I would urge against mixing tailwind and SASS if only for the build speed, PostCSS should be able to do everything you need there and it'll just make the builds a bit faster.

tho I feel like what myself and my team works on is a far cry from your standard HN web app - so my experiences are probably very different.

Post reply on HN