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

Working with Tailwind CSS every day for 2 years

themosaad.com

Post reply on HN
Print view View original

171–180 of 215 posts

Re: Working with Tailwind CSS every day for 2 years

#171

Post by onion2k »

kypro wrote: post #74
onion2k wrote: post #29

Earlier quoted context omitted.

It's loved by novices and those who don't know what they're doing, almost exclusively. I've been a frontend dev for 25 years and I quite like Tailwind. I'm not sure which category I fit into. I think it might be both. Replacing `p-4` with `p-4` will require you to replace its occurrence all over your app, sometimes affecting thousands of matches. This is a really good example of where Tailwind is actually quite nice.…

Variables would be the obvious answer here. If you're applying `p-4` to all your component classes you're only marginally improving on applying `padding: 8px` on all of your component styles. Both are terrible solutions even if one is slightly better than the other. I generally agree with OP. Tailwind is horrible for larger projects and I have no idea why it's so well liked. The utility class approach is bad, and nam…

Variables would be the obvious answer here.

Variables are very cool and super powerful, but they fall down if you need to support old browsers and it's really easy to make things that are hard to reason about (defined in several places, used in calc()s, overridden in the cascade, etc). On a team that doesn't communicate or test well vars can be a source of pain.

Re: Working with Tailwind CSS every day for 2 years

#172

Post by dmitriid »

satvikpendem wrote: post #167
dmitriid wrote: post #146

Earlier quoted context omitted.

Hm. I see the same CSS-in-JS with a sprinkle of string interpolation for some variables :) I may run into the same issues as the other CSS-in-JS solutions (I only encountered stitch once, and not for a long period of time)

Unlike other CSS-in-JS though, the way it's made, via object properties, enforces compliance to the design system. In things like styled-components, it doesn't. Doubly so when using TypeScript, as with Vanilla-Extract: https://vanilla-extract.style

> the way it's made, via object properties, enforces compliance to the design system.

The link literally has this:

``` export const className = style({ display: 'flex', flexDirection: 'column', selectors: { '&:nth-child(2n)': { background: 'aliceblue' } }, '@media': { 'screen and (min-width: 768px)': { flexDirection: 'row' } } }); ```

Which is indistinguishable from any other CSS-in-JS which has hundreds of these one-off things scattered everywhere. With a theme somewhere exposing another hundred or so variables of varing quality. And all these solutions basically converge on Tailwind (or other utility-first CSS approaches):

``` export const hero = style({ backgroundColor: vars.color.brandd, color: vars.color.white, padding: vars.space.large }); ```

is nothing more than `bg-brand color-white p-4`

But TypeScript support is definitely nice.

Re: Working with Tailwind CSS every day for 2 years

#173

Post by themosaad »

satvikpendem wrote: post #15

Having used Tailwind, once the class lists get large, it inevitably just becomes CSS classes again. My previous role had const headerStyles = ["bg-slate-100", "rounded-xl", "p-8" ...] ... ... and so on. So at that point, why use Tailwind anymore? Currently I use Vanilla-Extract, it's like SCSS but uses TypeScript instead of the SCSS language. It also compiles down into native CSS, so there's no runtime overhead like…

> Currently I use Vanilla-Extract, it's like SCSS but uses TypeScript instead of the SCSS language. It also compiles down into native CSS, so there's no runtime overhead like styled-components, emotion, etc.

I like Vanilla-Extract! Didn't wanna add to the article by talking about it and other alternatives I tried.

It solves the main two problems I encountered with Tailwind CSS by offering type-safety and low learning curve since you're mostly writing vanilla CSS.

However, some of its issues are:

- Isn't as widely supported as Tailwind CSS since it's exclusive to TypeScript (cannot use it in Laravel)

- Requires a special integration with each framework (couldn't use it with Remix.run)

- There's a runtime overhead when you use it inline via its Sprinkles package. Without it, you're back to thinking about class names and having your CSS in a separate file which I personally found not to be neither the most productive nor the most maintainable approach.

That being said, Vanilla-Extract author has recently Joined Remix.run and I hope they address some of these points soon.

Re: Working with Tailwind CSS every day for 2 years

#174

Post by satvikpendem »

dmitriid wrote: post #172
satvikpendem wrote: post #167

Earlier quoted context omitted.

Unlike other CSS-in-JS though, the way it's made, via object properties, enforces compliance to the design system. In things like styled-components, it doesn't. Doubly so when using TypeScript, as with Vanilla-Extract: https://vanilla-extract.style

> the way it's made, via object properties, enforces compliance to the design system. The link literally has this: ``` export const className = style({ display: 'flex', flexDirection: 'column', selectors: { '&:nth-child(2n)': { background: 'aliceblue' } }, '@media': { 'screen and (min-width: 768px)': { flexDirection: 'row' } } }); ``` Which is indistinguishable from any other CSS-in-JS which has hundreds of these one…

Sorry, could you reformat your code? I can't read this well.

Re: Working with Tailwind CSS every day for 2 years

#175

Post by themosaad »

johnchristopher wrote: post #27

> This plugin would allow me to use my existing CSS knowledge by writing: > Instead of: But... why ? I just don't get tailwind.

This is far from being the best example of WHY you should use Tailwind CSS. I wrote about the HOW.

I'll try to write another article about the WHY soon.

Re: Working with Tailwind CSS every day for 2 years

#176

Post by mixmastamyk »

naasking wrote: post #120
734129837261 wrote: post #22

I hate Tailwind with the passion of a million suns. It's loved by novices and those who don't know what they're doing, almost exclusively. They claim they know CSS, but will fail after any casual test. The best arguments against it: 1. Spamming utility classes causes horrible git commits, git history, git difference checks; 2. Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; 3. Rep…

Sounds like you don't know how to use Tailwind. Any front-end app is almost certainly already using a templating language, so declare your aggregate shared styles as variables there. Now you don't have to repeat your long style declarations in every context, and your 100 different markup files don't change if you want to make a minimal stylistic tweak (handling your point 1+3). Yes, you can do this sort of thing in C…

Happen to have a blog post link handy? Would like to see this strategy in more detail. With something like Django if possible.

Re: Working with Tailwind CSS every day for 2 years

#177

Post by themosaad »

darepublic wrote: post #34

I am tired of 'analysis' that looks like this: > Lightning-fast build times since March 15, 2021 Just put some numbers in there. Average code base size, average build time improvement since version x, etc. I can be the judge of whether that is "lighting fast" to me

> Just put some numbers in there. Average code base size, average build time improvement since version x, etc. I can be the judge of whether that is "lighting fast" to me

Fair enough. The video I linked to has some numbers Though. It used to take 19.44s to produce a 12MB CSS file in development vs a 1.9s to produce 11KB CSS file since this feature was released.

I believe it's even faster now (v3.1.8) as it only takes 260ms to produce a 29KB CSS file in one of my projects with dark mode and lots of variants.

Re: Working with Tailwind CSS every day for 2 years

#178

Post by naasking »

mixmastamyk wrote: post #176
naasking wrote: post #120

Earlier quoted context omitted.

Sounds like you don't know how to use Tailwind. Any front-end app is almost certainly already using a templating language, so declare your aggregate shared styles as variables there. Now you don't have to repeat your long style declarations in every context, and your 100 different markup files don't change if you want to make a minimal stylistic tweak (handling your point 1+3). Yes, you can do this sort of thing in C…

Happen to have a blog post link handy? Would like to see this strategy in more detail. With something like Django if possible.

Never used Django, but I see lots of videos/talks on Youtube discussing the combination of Django+HTMX+Tailwind (and sometimes also Alpine.js). Looks like some of them use Tailwind classes inline, but I assume Django has a way to bind from a model, in which case you can declare global static models for standard styling, like text inputs, charts, tabs, etc. and have those accessible to views.

Re: Working with Tailwind CSS every day for 2 years

#179

Post by whazor »

waboremo wrote: post #98
hbn wrote: post #50

Earlier quoted context omitted.

I really don't get the "tailwind is for beginners" opinion I see parroted so much. It doesn't enable you to do anything that CSS didn't already do. It's just a different way of writing it. Knowing CSS is a prerequisite to being able to use Tailwind. "Tailwind is for beginners" just sounds to me like "I don't like this thing because I'm too smart for it"

Because Tailwind is often suggested as a way for novices to implement design without having to really learn CSS. Simultaneously, allows people who don't care at all for CSS or design to create something functional. Tailwind does not require knowing CSS. It'll get you around tailwind faster if you do know it, but you do not have to care about what Tailwind is really up to when adding "outline outline-2 p-4 outline-off…

But almost every Tailwind shortcut translates to one line of CSS. So you need to know CSS, for example you understand words 'padding' and 'margin'. I did not know these words mean before learning CSS.

Re: Working with Tailwind CSS every day for 2 years

#180

Post by themosaad »

skilled wrote: post #81

I recently came to the conclusion that the best way to write CSS is through a Design System and write all the CSS yourself. And when I say Design System - I mean it can be your own or it can be external. The problem with writing a lot of CSS is that you will eventually run in circles and repeat yourself on the same elements with only small differences. A design system lets you adjust it all at once through Variables,…

I hope to work on a product where productivity isn't as essential as the quality of a design system to use such approach.

Saw the folks behind a CSS-in-JS library (Stitches) move to it recently[1]

However, they still saw the need for utility classes for cases where devs want to hack together something custom[2]

[1]: https://twitter.com/colmtuite/status/1572918908637650944 [2]: https://twitter.com/colmtuite/status/1572918911301218305

Post reply on HN