Live data from Hacker News

Tailwind CSS v4.0

tailwindcss.com

101–110 of 296 posts

Re: Tailwind CSS v4.0

#101
post #15

I love tailwind, used in 3 projects in the past 4 years, it’s intuitive, well documented, simple. I don’t miss the days of emotion and styled components where I would have to think of a name for every styled div in the project, with tailwind a container is just a div and a few classes nothing else. Less bike shedding discussion, less brain cycles spent naming things, less time wasted in reviews.

> a few classes You must be working with very good product owners then. The ones I've worked with love to specify the hell out of every possible detail. Like a web form is their personal HGTV renovation. I tried tailwind once and the classes ended up being an order of magnitude more than the markup. It got hard to read, quickly.

I generally use tailwind in combination with daisyui, and I don’t think about styling a lot any more beyond choosing the proper theme.

Re: Tailwind CSS v4.0

#102
post #80
post #77

Earlier quoted context omitted.

You clearly have a dependency on tailwindcss (if it can break you, you depend on it), and are using npm to fetch it (npx uses npm internally, they are installed together) so you can easily solve your problem by adding a couple json files with some version numbers in them. npx will pick up and use the version from your package.json, so no workflow change other than running `npm install …` once to generate package.json…

FFS we don't have local dependencies. Which means we don't have any local node_modules and have never ran npm install (there are no dependencies to install!). There is no lock file or dependencies. Our Apps don't have any npm dependencies nor needs to run npm install by design, we're not going to start now, as already stated we're switching to `tailwindcss@v3` instead. The point is this was a documented supported use…

I find it really hard to not immediately be reminded of this:

https://xkcd.com/1172/

Re: Tailwind CSS v4.0

#103

My initial reaction to Tailwind was: what a pain. I already know CSS, now I have to learn CSS again... I imagine its how parents might feel when they go to help their children with math homework only to find the math is now totally different from when they were in school and their methods (while still valid) for solving problems are no longer accepted by the school and their child is annoyed by having to reconcile th…

I think it’s because now your entire component is contained in a single file. No more separately messing around with CSS. The styles are right there on the element they apply to without having to cross reference anything.

You could do this with just the css attribute, but that has the issue that everyone has always been taught it is wrong to do that, and a list of strings that contain a bunch of utility is easier than writing those plain CSS objects.

Re: Tailwind CSS v4.0

#105
post #13

I appreciate there are people who find Tailwind useful and are productive with it, but it has this clean yet generic look that I now see everywhere, because Tailwind is now everywhere.

I heard this comment about Bootstrap back this in the day but none of my Bootstrap sites looked like each other. Bootstrap saved me a lot of time because it had a lot of utility classes (like Tailwind way before Tailwind) and it never enforced a certain look.

You just loaded the classes that you wanted (unless you didn’t download the source Sass files, but that would have been silly).

Re: Tailwind CSS v4.0

#106
post #77

Earlier quoted context omitted.

You clearly have a dependency on tailwindcss (if it can break you, you depend on it), and are using npm to fetch it (npx uses npm internally, they are installed together) so you can easily solve your problem by adding a couple json files with some version numbers in them. npx will pick up and use the version from your package.json, so no workflow change other than running `npm install …` once to generate package.json…

FWIW Tailwind can be used as a standalone executable. This is how Phoenix/Elixir bundles Tailwind without requiring npm.

I don’t care how you do it, just make getting your dependencies deterministic based on files committed to your repo!

Happily the Tailwind hex package encourages you configure a fixed version number, so you’ll never get surprise breakage as long as you’re committing your mix.lock file as well.

I’m only suggesting package.json/package-lock.json because their projects are already using the npm ecosystem to fetch the tailwind dependency. A Makefile that does `curl $TAILWIND_GITHUB_RELEASE_URL -o ./departing/tailwind` is fine too (this is what Tailwind.hex is doing under the hood).

Re: Tailwind CSS v4.0

#107

As a once-strident critic of Tailwind for its many failings and incompatibilities with the state of the actually-modern "vanilla" web art, I am very pleased to see the huge strides they've made with v4. Being able to access the Tailwind theme through native CSS variables (they even have an example in the docs of a button component written in native CSS in an external stylesheet using native variables! Oh happy day!)…

> I suspect many of the pro/anti-Tailwind arguments are no longer relevant I feel there are two issues with Tailwind for me as a designer / design engineer. * First, JavaScript/Tailwind engineers have hijacked the conversation on design. Instead of "utility-first," "dead code elimination," and "type-safe CSS" I focus more on desing systems. Whether to use Perfect Fifth or Perfect Fourth in typography for example. * S…

No one cares what your typography ratio is if you can’t get it in front of a user quickly enough (dead code elimination), reliably enough (type safe), or cost effectively enough (i.e. if you have to pay for more developer time to implement the same work).

Tailwind is a tool for craftspeople, not artists. It democratises design by making it simpler. For folks that are really good designers, they should be happy that they can up their prices knowing that customers are paying for their expert eye, rather than just the basics again and again.

Re: Tailwind CSS v4.0

#108

Earlier quoted context omitted.

"Basically just inline CSS, but less fiddly and much more optimizable than the style attribute" was always the selling point of Tailwind in the first place.

Then , yes. But nowadays CSS is a lot more powerful and has caught up. So why bother with Tailwind?

A concrete example that seems like a no-brainer to me: let's add a little padding to the top and bottom of an element. "py-2" Done. In CSS, specifying padding (or margins) is 4 values... except I forget which is the first one. And what units should I use... px, pt, rem, em. Inline, same-page style, or an external .css file? If not inline, what should I name the class? Vanilla CSS literally requires 10x more time and mental attention.

Re: Tailwind CSS v4.0

#109
post #102
post #80

Earlier quoted context omitted.

FFS we don't have local dependencies. Which means we don't have any local node_modules and have never ran npm install (there are no dependencies to install!). There is no lock file or dependencies. Our Apps don't have any npm dependencies nor needs to run npm install by design, we're not going to start now, as already stated we're switching to `tailwindcss@v3` instead. The point is this was a documented supported use…

I find it really hard to not immediately be reminded of this: https://xkcd.com/1172/

We only use npm dependencies and bloated node_modules folders [1] if we absolutely have to and for our non node.js Apps we explicitly don't.

[1] https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/hea...

Re: Tailwind CSS v4.0

#110
Question for those developers who, like me, have no f/end build step: How would I use tailwind without a f/end build step? All the examples of using tailwind 4.0 on the linked site assume a f/end build step.

My project does not use (and I have no plans to include) npm, or PostCSS, etc.

Post reply on HN