Hacker News Reader

Comment by atonse | Hacker News Reader

Our build times for our ember JS app went from 60 seconds to something like 7-8 minutes since including tailwind. And TailwindJIT introduced some odd bugs where we had to leave it off. So far it's made the dev harder in some ways that have nothing to do with all the actual CSS benefits we realized. We'll try 2.2 to see if it helps.

I am really hoping someone is working on a go or rust version of the tailwind compiler, and we'll see those speeds come down from multiple minutes down to 800ms and see just how utterly silly JS tooling performance is.

View on HN

Hey! Sorry to hear about this — the core of the problem you’re facing I expect is that build tooling struggles very much with large CSS files, so no matter how fast you can generate the CSS, if it’s like 8mb because you have a rich config file and you’re in development so you’re not purging, the overall build is going to be slow. We’ve tested this a bunch by feeding static CSS files of this size into webpack without having Tailwind in the build process at all.

The JIT engine is our solution to this, and ensures the CSS file is never large so it never causes these issues. We have done a ton of work to iron out bugs in the new engine between 2.1 and 2.2 so I would definitely give it a shot and see how it goes.

Consider even using our new CLI tool to compile your CSS instead of integrating it into your Ember build step — on the biggest project we’ve tried (over 400 template files, some thousands of lines long), the new CLI compiles the CSS in about 400ms, and incremental rebuilds when you save a template file take 3–10ms.

Thanks for continuing to improve it. I will try it again though with your suggestion to do it independently to find the bottleneck.

In spite of the build times, we like tailwind so we’ve kept it!

It’s just that we get a lot more “you’re running out of build time” emails from Netlify these days :-)

Tailwind JIT is really fast, drastically cut my build times down. I don’t like how slow JS tooling can be either. The JIT compiler makes a big difference.

You can try windicss https://windicss.org/

This is tailwind but on steroids. The author was frustrated with slow speed so he started the project. Windicss by default only generate css for classes or attributes you are using. This is equivalent to tailwind jit.

What kind of bugs have you seen? I haven't tried Tailwind JIT yet but I'm hoping to eventually switch over a work project and I'd love to have some idea of when I'm getting myself into.

We saw a couple bugs that only happened in jit mode in prod builds. I’ll have to ask our dev what it was.

What made you switch to tailwind in the first place?

With our bootstrap theme we found we were dropping to style overrides a lot. Also, the purging support ensures that only classes we use will make it in the final css.

Those two features themselves were quite appealing.

Reply on news.ycombinator.com