The name "Stack" here means a starter template for the Remix framework e.g. Remix Stacks https://remix.run/docs/en/main/pages/stacks

That's a good side effect from using Tailwind CSS docs. They curate new CSS properties and add the most important (in their opinion) once they're supported by all modern browsers.

Forgot to mention that I no longer do these conversions for the most part, instead, I scroll down the suggested values from the Tailwind CSS IntelliSense VSCode extension since it displays the equivalent values in pixels.

Great work scratching your own itch! Not as easy addition to the workflow as it doesn't have a CLI but I think that's intentional or not a priority for you.

I backed out from maintaining a big Tailwind CSS plugin let alone create my own solution.

Similar to React, I don't think Tailwind CSS is easy to replace regardless of the slightly better alternatives that exist or might popup up due to its established community.

I do dislike long walls of classes as well. However, I'm yet to find an alternative that offers the same benefits Tailwind CSS offers without such compromises.

Wrote about Vanilla-Extract shortcomings here https://news.ycombinator.com/item?id=33793944

I hope to work on a product where productivity isn't as essential as the quality of a design system to use such approach.

Saw the folks behind a CSS-in-JS library (Stitches) move to it recently[1]

However, they still saw the need for utility classes for cases where devs want to hack together something custom[2]

[1]: https://twitter.com/colmtuite/status/1572918908637650944 [2]: https://twitter.com/colmtuite/status/1572918911301218305

> Just put some numbers in there. Average code base size, average build time improvement since version x, etc. I can be the judge of whether that is "lighting fast" to me

Fair enough. The video I linked to has some numbers Though. It used to take 19.44s to produce a 12MB CSS file in development vs a 1.9s to produce 11KB CSS file since this feature was released.

I believe it's even faster now (v3.1.8) as it only takes 260ms to produce a 29KB CSS file in one of my projects with dark mode and lots of variants.

This is far from being the best example of WHY you should use Tailwind CSS. I wrote about the HOW.

I'll try to write another article about the WHY soon.

I think something clicked yesterday after reading a comment. It works for SPA/css-in-js/components-based projects, and this long class string is manageable as long as it is only present in one single place in the whole project (thinking about versioning and the mental model of where's what).

> Currently I use Vanilla-Extract, it's like SCSS but uses TypeScript instead of the SCSS language. It also compiles down into native CSS, so there's no runtime overhead like styled-components, emotion, etc.

I like Vanilla-Extract! Didn't wanna add to the article by talking about it and other alternatives I tried.

It solves the main two problems I encountered with Tailwind CSS by offering type-safety and low learning curve since you're mostly writing vanilla CSS.

However, some of its issues are:

- Isn't as widely supported as Tailwind CSS since it's exclusive to TypeScript (cannot use it in Laravel)

- Requires a special integration with each framework (couldn't use it with Remix.run)

- There's a runtime overhead when you use it inline via its Sprinkles package. Without it, you're back to thinking about class names and having your CSS in a separate file which I personally found not to be neither the most productive nor the most maintainable approach.

That being said, Vanilla-Extract author has recently Joined Remix.run and I hope they address some of these points soon.