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

Tailwind CSS v4.0

tailwindcss.com

Post reply on HN
Print view View original

71–80 of 296 posts

Re: Tailwind CSS v4.0

#71

Post by homarp »

loxs wrote: post #68
davidw wrote: post #62

Earlier quoted context omitted.

The DaisyUI description of the Tailwind button made me laugh: "bg-indigo-600 px-4 py-3 text-center text-sm font-semibold inline-block text-white cursor-pointer uppercase transition duration-200 ease-in-out rounded-md hover:bg-indigo-700 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-indigo-600 focus-visible:ring-offset-2 active:scale-95" Yeah, that's not making my life easier is it. Also some of t…

They are cryptic but the learning curve is not that steep. Once you get the idea, it becomes much easier (and quite pleasant for a CSS hater like me). For example px-3 means "padding on the x axis 3 (spacing values)" and gives you padding on both left and right. There is a (rather simple) language that you need to learn and at least for me it made things much, much better. You can probably get the feel for it in seve…

ia that really easier than learning css directly? since you have to understand 'paddding'and 'px' ?

see https://developer.mozilla.org/en-US/docs/Web/CSS/padding

vs https://tailwindcss.com/docs/padding

Re: Tailwind CSS v4.0

#72

Post by Sateeshm »

todd3834 wrote: post #38

I’m a recent convert to tailwind. I’m very comfortable with css and I was initially turned off on the huge horizontal lines I saw in tailwind projects. However, more and more component libraries are based on tailwind so I decided to try some immersion therapy. Here are the top things I enjoy that was not obvious to me: 1. The class names are css shortcuts. Using them save you a lot of time. This is probably obvious t…

It's sort of like javascript devs ignoring typescript because they never felt like they needed it. But once you start using it, it's difficult to go back.

I was in never ts/tailwind gang for a few years until I tried them.

Re: Tailwind CSS v4.0

#73

Post by jitl »

mythz wrote: post #67

Was it really necessary to break all existing apps using `npx @tailwindcss`? It's an easy enough change to `npx @tailwindcss/cli` but we now have to go back and update all Apps and templates and since it uses v4 we now have to test every App to see if anything's broken with a v4 major release. Given its massive install base, surprised they wouldn't maintain backward compatibility with v3 and have an explicit opt-in u…

You’re doing something silly living without a lock file to use a tool as part of your build process. Why don’t you actually include the version of the tool you want in your dev dependencies + lock file? That way, you don’t get broken. We’ve had the solution to this problem - lock files - for 15ish years, since Ruby’s `bundle` introduced it.

Re: Tailwind CSS v4.0

#74

Post by rayrrr »

crummy wrote: post #4
rglullis wrote: post #2

"Build times reduced", "no more @tailwind directives", "No more js configuration", "Designed for the modern web". To me, this screams "CSS now can do everything we used to do ourselves, but let's keep pretending that we are still needed somehow"

What did you need Tailwind for before that you couldn't do in normal CSS? Doesn't Tailwind map pretty much 1:1 to CSS?

Every programming language maps 1:1 to CPU instruction sets, but very few humans want to speak CPU language directly…hope that helps.

Re: Tailwind CSS v4.0

#75

Post by mythz »

jitl wrote: post #73
mythz wrote: post #67

Was it really necessary to break all existing apps using `npx @tailwindcss`? It's an easy enough change to `npx @tailwindcss/cli` but we now have to go back and update all Apps and templates and since it uses v4 we now have to test every App to see if anything's broken with a v4 major release. Given its massive install base, surprised they wouldn't maintain backward compatibility with v3 and have an explicit opt-in u…

You’re doing something silly living without a lock file to use a tool as part of your build process. Why don’t you actually include the version of the tool you want in your dev dependencies + lock file? That way, you don’t get broken. We’ve had the solution to this problem - lock files - for 15ish years, since Ruby’s `bundle` introduced it.

Not everything is a node App. We don't have a lock file because we don't have any local npm dependencies (as already mentioned). We're using `npx tailwindcss` as-is.

Re: Tailwind CSS v4.0

#76

Post by loxs »

homarp wrote: post #71
loxs wrote: post #68

Earlier quoted context omitted.

They are cryptic but the learning curve is not that steep. Once you get the idea, it becomes much easier (and quite pleasant for a CSS hater like me). For example px-3 means "padding on the x axis 3 (spacing values)" and gives you padding on both left and right. There is a (rather simple) language that you need to learn and at least for me it made things much, much better. You can probably get the feel for it in seve…

ia that really easier than learning css directly? since you have to understand 'paddding'and 'px' ? see https://developer.mozilla.org/en-US/docs/Web/CSS/padding vs https://tailwindcss.com/docs/padding

I am not going to argue whether that's the case, as I never managed to learn CSS enough to be productive in a convenient (for me) way. Despite of trying many times. Whereas tailwindcss "clicked" right away and gave me the awesome superpower to build whole products without having to depend on other people. Before that I hated myself for the horrible, unmaintainable mess that I created, and double hated myself later when I had to revisit the project. Since I am using tailwindcss, I never had bad experience. Of course I still have to spend time wondering how to center some element and why it doesn't work, but that's not what I am complaining about.

It might be just a personal defficiency, but it is how it is (for me).

Re: Tailwind CSS v4.0

#77

Post by jitl »

mythz wrote: post #75
jitl wrote: post #73

Earlier quoted context omitted.

You’re doing something silly living without a lock file to use a tool as part of your build process. Why don’t you actually include the version of the tool you want in your dev dependencies + lock file? That way, you don’t get broken. We’ve had the solution to this problem - lock files - for 15ish years, since Ruby’s `bundle` introduced it.

Not everything is a node App. We don't have a lock file because we don't have any local npm dependencies (as already mentioned). We're using `npx tailwindcss` as-is.

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 for your preferred semver specifier, and package-lock.json to guarantee your builds use a known-good version from now on.

Re: Tailwind CSS v4.0

#78

Post by rayrrr »

To some extent, reading between the lines of many of these comments, I think “pure CSS” designers are feeling threatened by the quality level of Tailwind sites designed by the rest of us.

Re: Tailwind CSS v4.0

#79

Post by bern4444 »

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 the two systems...

I get the, tailwind works well in a team and scales nicely and you just have to use it, mentality. I've experienced it.

I still prefer a plain style sheets that targets elements by a class or tag (especially since CSS supports nested selectors!).

There is an issue in managing stylesheets, and for that I really like how Remix/React Router manages CSS where CSS flies are defined and applied at the route level. Where that isn't enough or dynamic styles are too complex for a .css file:

    style={{...}}
is always available.

CSS is so powerful, flexible, and extensible, tailwind feels like a limitation rather than an enhancement. I don't understand the continued appeal, but clearly many others do. I'm not sure why, but I am confident we'll all have moved on to something else in another 3 or 4 years too.

Re: Tailwind CSS v4.0

#80

Post by mythz »

jitl wrote: post #77
mythz wrote: post #75

Earlier quoted context omitted.

Not everything is a node App. We don't have a lock file because we don't have any local npm dependencies (as already mentioned). We're using `npx tailwindcss` as-is.

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-case which all our non node.js Apps used, which have now broken as a result of this release.

Post reply on HN