Hacker News Reader

Comment by varun_ch | Hacker News Reader

While I agree with most of the arguments here, this article feels a little contradictory - it recommends Tailwind but also tells us to 'stay clear of build steps'. Shipping massive CSS/JS resources goes against the whole inclusivity principle - many people don't have super fast internet connections or powerful enough computers..

View on HN

I don't use Tailwind anymore at the moment, but in my experience, it does not lead to shipping massive CSS/JS resources. In fact I don't know about any client-side JS at all that is emitted by Tailwind (my last experience was 2.x, not sure if anything has changed).

Regarding the CSS size, my experience was the opposite, Tailwind output was usually a lot smaller than hand-written CSS.

I have nothing against plain CSS either though; but it's at least as easy to make a mess.

I think what the OP meant is: Tailwind requires a build step to extract use classes. Otherwise you need to ship all of it.

It's true that it requires a build step, since tw 2, AFAIK there's not even a way anymore to ship "all of it". CSS rules are generated on-demand for the classes that match tailwinds syntax.

I think GP is talking about how, without the tailwind build step, you ship all of tailwind, which is unquestionably a lot of CSS that you aren't using.

Maybe if you use a CDN, so hopefully the user might have a local cache of it from somewhere else, that can be avoided?

Still though, tailwind is pitched WITH it's build step normally, making the author's point about avoiding a build step a bit odd.

This was only the case in Tailwind 1 and heavily discouraged by the documentation, except for development.

Tailwind requires a build step and shipping the 1.x development build was explicitly not meant for production.

Trying to use tw 1 like this without a build step, you can't even define a custom color scheme.

If this is what you want, I'd use a library that actually supports this. Maybe tachyons? But tbh, without the build step I'd consider using Tailwind at all a massive mistake. Then I'd prefer handwritten CSS.

Custom properties should make sth like this a lot more viable though. I'm sure there are libraries that better fit this use case, if you want to use a CSS library.

> Maybe if you use a CDN, so hopefully the user might have a local cache of it from somewhere else, that can be avoided?

Browsers partition caches by origin now for privacy reasons, so this is no longer possible. If the user doesn’t have it cached from your website, they don’t have it cached.

Did your experience involve the (recommended) build step? It uses, at least last I checked, a purgeCSS step to remove unused rules and decrease the css size.

This changed in tw 2, everything is generated on demand, PurgeCSS is no longer used.

> Tailwind output was usually a lot smaller than hand-written CSS:

Tailwind output is massively bigger than the one with semantic CSS. Here's a comparison:

https://nuejs.org/blog/tailwind-vs-semantic-css/

I made an atomic CSS library that doesn't need a build step, if anyone wants one (spoiler, nobody does): https://casscss.github.io/cass/

Imho, bullet points on the border box seems weird to me (https://ibb.co/d0sDsQ2).

Thanks for the note! The left padding and margin situation on the ul is the bane of my existence.

Copy what other more popular frameworks are doing :P

I haven't looked at your css, but maybe changing the box model could help?

Deno Fresh uses Twind, which avoids the build step: https://twind.dev/

But IIRC it doesn't offer quite everything full Tailwind does. In general I was frustrated with Fresh for not being up-front about the fact that it is largely built on Preact and Twind, and you must buy into those libraries first.

Tailwind has a standalone CLI which can be used for the build step. I do sort of agree that it's a bit of an odd recommendation in the context of this article, but the build step can be extremely minimalistic, and another nice thing is that the results are still inspectable CSS.

I use tailwind on my personal site, which is otherwise entirely just vanilla HTML, and it doesn't feel very intrusive to run the CLI in watch mode when I'm writing styles.

Good options for zero build:

* Self host tailwind v3 CDN.

* https://github.com/gnat/css-scope-inline

Both are surprisingly fast- parse 10,000+ <style> or class="..." in under a second.

You don't ship Tailwind...

The OP was making a point that the build step should not be required to run/display a web app.

For example, tailwind without a build step is just the entire library. This means one can go a long way and even have a functioning web application without introducing a build step.

I would say stripping unused CSS is in the same context as optimizing images, fonts etc perhaps generally a "cleanup & prepare assets for production" step.

I read it the same way, yes. Good point with the cleanup: - it’s one thing to need to run build for it to work; - it’s another thing to run build to make it smaller;

Tailwind doesn't exist without a build step (at least since v2) — the whole point of Tailwind is that it is a build tool, an alternative syntax for writing CSS.

There's a kind of development version where that build step runs in the browser on page load, but it's still a build step in the sense of generating all that CSS dynamically, and it will produce a poor experience for a user if you try and use it in production.

The only thing a build step changes about CSS/JS resources of this kind, is a minimization of the libs...which is entirely achievable without building, by simply including the already-minimized version.

I think what the article is about when it says to steer clear of builds, is complex builds, where transpilations and similar changes in format have to happen, in order for the page to work.

> The only thing a build step changes about CSS/JS resources of this kind, is a minimization of the libs...which is entirely achievable without building, by simply including the already-minimized version.

This isn't true, though—Tailwind's build step isn't just stripping out white space, it removes unused selectirs, too, which can't be done in advance.

I wasn't aware of that, thanks :-)

Reply on news.ycombinator.com