Most active commenters
  • that_guy_iain(3)

←back to thread

Tailwind CSS v4.0 Beta 1

(tailwindcss.com)
159 points creativedg | 17 comments | | HN request time: 0.001s | source | bottom
1. that_guy_iain ◴[] No.42211038[source]
I'm really curious as to why they felt the need to work on improving performance.[1]

Were people complaining it was too slow? Were the performance improvements just the benefit of refactoring they did for other reasons?

Considering the build happens once during your build phase, taking under half a second doesn't seem like something I would even bother looking at. So it just jumps out to me, so I'm just curious.

[1] https://tailwindcss.com/docs/v4-beta#new-high-performance-en...

replies(5): >>42211115 #>>42211179 #>>42211209 #>>42211283 #>>42211498 #
2. sodapopcan ◴[] No.42211115[source]
No idea if anyone was complaining, but if building in CI it shaves off some pennies (or more?) no?
replies(1): >>42211399 #
3. ripley12 ◴[] No.42211179[source]
I absolutely care about things that take hundreds of milliseconds for my builds. The faster I can build, the faster I can iteratively try new things things out. The goal should be to be able to see changes instantly after you make them, and Tailwind is usually just 1 part of a build pipeline.

Bret Victor's Inventing on Principle is probably the best demonstration of why this matters; in the first 10 minutes he shows a very concrete example of an insight that would not have occurred without instant feedback https://www.youtube.com/watch?v=EGqwXt90ZqA

replies(1): >>42211282 #
4. dcre ◴[] No.42211209[source]
I think a lot of the optimization work was for dev time and it carried over to build time. I listened to a podcast interview with Adam Wathan where I think he said they just got really into shaving nanoseconds. They have a very successful business and I think they just enjoyed doing this work. On the other hand I do think even if you’re cutting from 50ms to 5ms (both low numbers in absolute terms) there are often new unforeseen workflows that become possible once you can do that operation so frequently that it’s free. You could do it on every keystroke.
replies(1): >>42211423 #
5. that_guy_iain ◴[] No.42211282[source]
> I absolutely care about things that take hundreds of milliseconds for my builds. The faster I can build, the faster I can iteratively try new things things out. The goal should be to be able to see changes instantly after you make them, and Tailwind is usually just 1 part of a build pipeline.

When we're talking about ms the build is not the thing that is affecting your ability to try new things out. It was already so fast it was near instant.

replies(1): >>42211392 #
6. asimpletune ◴[] No.42211283[source]
Despite tailwind 3 being very fast there are situations where it can be a little slow and it adds up. I’m personally really glad they’re tackling performance in v4.
7. ripley12 ◴[] No.42211392{3}[source]
1. Tailwind is just 1 part of a build system, and it all adds up

2. Watch Inventing on Principle if you haven't already. Pushing build times into milliseconds or sub-milliseconds enables new capabilities

replies(1): >>42211535 #
8. teaearlgraycold ◴[] No.42211399[source]
Given its popularity this can actually get into measurable carbon emission savings. Not world changing. But maybe a few international flights over the lifespan.
replies(1): >>42212062 #
9. joshdavham ◴[] No.42211423[source]
> there are often new unforeseen workflows that become possible once you can do that operation so frequently that it’s free. You could do it on every keystroke.

That’s really interesting to think about actually! What kinds of practical things do you think could be enabled by an extremely fast tailwindcss?

replies(2): >>42211602 #>>42211714 #
10. emmanueloga_ ◴[] No.42211498[source]
I think the rewrite aimed to simplify installation and configuration. TW 4.0 switched from PostCSS to LightningCSS [1], and Rust-based tools tend to offer a simpler setup via single binaries (in contrast to the complexity of typical JS-based tools).

Moving from pure JS to Rust also brings performance gains. Even if the main goal wasn't "performance," it's a nice side effect worth highlighting.

--

1: https://lightningcss.dev/

11. that_guy_iain ◴[] No.42211535{4}[source]
If you want to try new things out and move fast with your CSS, you're not building the entire system. It's a partial build and that was already faster than you would even be able to react. Your browser refreshing would take longer.
replies(1): >>42213978 #
12. mattigames ◴[] No.42211602{3}[source]
LLM trying design using tailwind, stuff like: try to recreate this bitmap image using tailwind utility classes; the iteration speed for that kind of tasks depend on such speed.
13. LaundroMat ◴[] No.42211714{3}[source]
Live reloading
14. Sesse__ ◴[] No.42212062{3}[source]
The carbon cost of a bloated CSS framework isn't the build time, it's the billions of times the resulting CSS has to be parsed and applied on the web pages where it's used.
replies(1): >>42213135 #
15. yurishimo ◴[] No.42213135{4}[source]
Have you examined the build artifacts of a site using tailwind? The size of the CSS is often smaller than the same styling in "normal" hand written CSS. There are a dozen blog posts from large engineering orgs that have confirmed that switching to Tailwind slimmed their builds down. Shopify has been a big proponent of Tailwind and they are absolutely obsessed with shipping as little code as possible because of the scale they operate at.

Also, browsers are insanely good at parsing and applying CSS. You need hundreds of thousands of unique selectors before the browser takes more than fraction of a second to parse and render an entire CSS file.

https://www.trysmudford.com/blog/i-spent-a-day-making-the-we...

replies(1): >>42213186 #
16. Sesse__ ◴[] No.42213186{5}[source]
Yes, I have. I work on browser CSS performance.
17. ◴[] No.42213978{5}[source]