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

Tailwind CSS v4.0 Beta 1

tailwindcss.com

Post reply on HN
Print view View original

121–130 of 135 posts

Re: Tailwind CSS v4.0 Beta 1

#121

Post by PortSaturation »

c-hendricks wrote: post #106
jamie_ca wrote: post #105

Earlier quoted context omitted.

Also: When served from a CDN like your link above, popular CSS like Bootstrap had a decent chance of _already_ being in your browser's cache, so despite downloading more initially you'd come across sites using the same version that meant _no_ delay downloading CSS for it.

Isn't this outdated information? https://httptoolkit.com/blog/public-cdn-risks/ > Most importantly: cached content is no longer shared between domains. This is known as cache partitioning and has been the default in Chrome since October 2020 (v86), Firefox since January 2021 (v85), and Safari since 2013 (v6.1). That means if a visitor visits site A and site B, and both of them load https://public-cdn.example/my-scrip…

It was (and still is) never a good idea to hotlink to an external dependency.

Most developers know better than to hotlink to an image because it might one day return a completely different image (and potentially an unsavory one) yet they casually use external code dependencies.

It is also why the Dependabot(sp?) that has become so popular among devs makes me nervous. Something automatically updating your dependencies is a recipe for disaster.

Re: Tailwind CSS v4.0 Beta 1

#122

Post by floydnoel »

renerick wrote: post #98

After some experimenting I found that Tailwind works best with hybrid approach. The essay[1] is correct, that often you have one-of-a-kind blocks, like headers, footers, etc. that you can just fully implement with TW utilities, reducing cognitive load for class naming and structuring. But for more reusable elements, like buttons, links, inputs, popups, it's just much nicer to have them (and their variations) behind s…

I use DaisyUI on top of Tailwind to get the nice semantic classes like btn.

Re: Tailwind CSS v4.0 Beta 1

#123

Post by rnewme »

dotancohen wrote: post #67
ssijak wrote: post #64

Earlier quoted context omitted.

What is the issue? Except you not being up to date with the ecosystem and complaining about it? Why do I need a car key and worry about gasoline? I can just hop on a horsie and ride away!

So Vite is a security measure against opportunistic theft? Theft of what? Hey, I yearn for the days of good car analogies too. But the car key is not an essential part of the car experience, rather a necessity borne of the distrust of follow man.

Theft of bandwidth.

Re: Tailwind CSS v4.0 Beta 1

#124

Post by rnewme »

Leonelf wrote: post #76
kookamamie wrote: post #46

Read some of the Getting Started documentation, for fun. First step: > Installing with Vite What the hell is Vite? Oh, it seems to be something you need to install via npm. I cannot help but to ask - why do we require npm, or Vite, for something that looks like it should "help" with CSS? Why is the webdev such a shitshow, that seems to get ever deeper into its own weird rabbit hole?

Are you just lazy? Apart from not being up to date with common ecosystems (which I'd expect when doing anything web), look at the Getting Started: Getting started ->Installing with Vite ->Installing with PostCSS ->Installing the CLI ->Upgrading from v3 At the bottom of the CLI paragraph it says "You can also download standalone builds of the new CLI tool from GitHub for projects that don’t otherwise depend on the Nod…

It's not lazyness, it's repulsion by the fact everything rots after 6 months.

Re: Tailwind CSS v4.0 Beta 1

#125

Post by naasking »

emmacharp wrote: post #92

I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me: Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!). The time has come to embrace good ol' CSS again! Heheh.

> Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!).

I'd like to not have to read or write CSS. Let's see you tackle that. ;-)

Re: Tailwind CSS v4.0 Beta 1

#126

Post by Vinnl »

emmacharp wrote: post #94
Vinnl wrote: post #93

Earlier quoted context omitted.

Ok, my problem is that I don't know just by reading the styles that other contributors wrote, whether they are still relevant, or if the HTML they applied to was changed or removed. They didn't write clean atomic commit, and I can't get them to adhere to some sort of convention. The other problem is that I don't have a designer and tend to make things ugly given full freedom, but I do want things to have their own vi…

Great questions/problems! 1. I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either. A positive side effect of this technique is that you always have an easy access to the CSS by following the link in your editor of choice. As for the relevance of the rules inside the component, the said component should be light/simple enou…

> I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either.

Do the selectors in those style tags not apply globally? How do I prevent contributors (including myself) from accidentally writing a selector that affects HTML in other components? I see ECSS allows plain tag selectors for example?

Isn't the design token variable file quickly going to balloon? As you mention, it looks like Tailwind provides this now as well, but you'll still want to run the build step of generating the minimal style sheet that provides only the tokens you actually use, rather than having to compile that style sheet manually.

As a related question: if you're already running Stylelint, what's the problem with a build step?

And: is the CSS on Tailwind's homepage actually unused, or used in dynamically added HTML? Is the additional download+parse size actually significant, or does it e.g. compress well and not affect performance that much? Throttling network speed at least doesn't result in a terrible loading experience for me, it seems.

Re: Tailwind CSS v4.0 Beta 1

#127

Post by Vinnl »

naasking wrote: post #125
emmacharp wrote: post #92

I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me: Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!). The time has come to embrace good ol' CSS again! Heheh.

> Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!). I'd like to not have to read or write CSS. Let's see you tackle that. ;-)

Well, Tailwind doesn't really solve that for you either - you pretty much have to know CSS to be able to use it effectively, in my experience. Technically, you may not really be writing CSS, but in practice, I think all the reasons you might have for not wanting to write CSS still apply to writing Tailwind.

Re: Tailwind CSS v4.0 Beta 1

#128

Post by naasking »

Vinnl wrote: post #127
naasking wrote: post #125

Earlier quoted context omitted.

> Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!). I'd like to not have to read or write CSS. Let's see you tackle that. ;-)

Well, Tailwind doesn't really solve that for you either - you pretty much have to know CSS to be able to use it effectively, in my experience. Technically, you may not really be writing CSS, but in practice, I think all the reasons you might have for not wanting to write CSS still apply to writing Tailwind.

Not quite, with Tailwind:

1. you need to know the specific effects of the individual directives but you don't need to deal with the cascading behaviour and other complexities.

2. you don't need to leave your local markup to make styling changes.

3. you don't need to synchronize selectors across multiple files (non-locality).

And because Tailwind involves a lot of repetition of the same CSS classes for the same markup, it naturally drives you towards defining reusable HTML components that encapsulate the markup and CSS classes.

There are a lot of subtle usability improvements like this that avoid CSS footguns and make dev UX better overall.

Re: Tailwind CSS v4.0 Beta 1

#129

Post by emmacharp »

Vinnl wrote: post #126
emmacharp wrote: post #94

Earlier quoted context omitted.

Great questions/problems! 1. I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either. A positive side effect of this technique is that you always have an easy access to the CSS by following the link in your editor of choice. As for the relevance of the rules inside the component, the said component should be light/simple enou…

> I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either. Do the selectors in those style tags not apply globally? How do I prevent contributors (including myself) from accidentally writing a selector that affects HTML in other components? I see ECSS allows plain tag selectors for example? Isn't the design token variable fil…

1. The stylelint config will flag any selector not scoped (be it a class or an attribute) to the filename. This way you'll be notified if any selector could be misapplied essentially preventing these global accidents.

2. You could use a build step for this, yes. Personally, I don't because the theme files more or less contain always the same tokens. I rarely add any (colors being the most frequent) and if I do, the cost of it being unused is minimal. My standard full theme file is around 5kb.

3. Stylelint complements my work but isn't necessary. My code does not depend on it to work, contrary to Tailwind, for instance. I'm free to stop using it any time.

4. It's a monolothic file containing all the code needed for the whole site and not only the page I'm looking at now. It may not make that much of a difference in performance, but still, the browser downloads CSS code it does not need now and then must read through all of it to apply needed rules. Not optimal.

By the way, it's great you came back with further questions! Hope to have addressed them at your satisfaction. Still at your disposal if you have more!

Re: Tailwind CSS v4.0 Beta 1

#130

Post by emmacharp »

naasking wrote: post #128
Vinnl wrote: post #127

Earlier quoted context omitted.

Well, Tailwind doesn't really solve that for you either - you pretty much have to know CSS to be able to use it effectively, in my experience. Technically, you may not really be writing CSS, but in practice, I think all the reasons you might have for not wanting to write CSS still apply to writing Tailwind.

Not quite, with Tailwind: 1. you need to know the specific effects of the individual directives but you don't need to deal with the cascading behaviour and other complexities. 2. you don't need to leave your local markup to make styling changes. 3. you don't need to synchronize selectors across multiple files (non-locality). And because Tailwind involves a lot of repetition of the same CSS classes for the same markup…

1. Which part of the cascade do you struggle with? Because it can make your code really simple and efficient!

2. If you link your CSS inside your component you have a direct access to it. A simple editor split suffice to edit it. I would say that's a pretty standard workflow.

3. You can force (with Stylelint, for instance) the use of scoped selectors in CSS files, essentially preventing any selector spillover (which is a real problem). Scoping component selectors inside the one and only corresponding CSS file is important and achievable without complex code dependencies.

4. The drive to define reusable components should already be natural enough on its own! Heheh.

By approaching CSS with the good tools and mindset, you can have a great dev experience while preventing complex dependency chains, third party rules/lock-in. You can also use the most recent CSS features not implemented in Tailwind (looking at you clamp()!) to provide a better end-user experience more easily.

It's a great time to rediscover CSS!

Post reply on HN