@amnu3387 would be the expert in that. That would be quite incredible if that could work. I know he was looking at quite a few specs.
Super-interesting idea. I suppose the stability would depend on how many dependencies are pulled in to create it, but at least the end-user would be guaranteed a working tool.
There are Tailwind-like CSS frameworks written in SASS, https://uniformcss.com/ for example. However, I don’t know how CSS purging is done in sass. I guess you have to use PurgeCSS and with that you have dependency on node. This is a tough nut to crack 
Deno is much less compelling for me, but admittedly it’s because I expect churn there as well given the proximity to the js ecosystem and early lifecycle, which may be an unfair bias. I would love something that allowed me to achieve the tailwind css design language/feature-set with either an elixir port or failing that, single binary executable, which is what deno could offer. That said, it would need to be a complete solution – not only the postcss bits. I imagine for most folks, the tailwind cli is hard to beat for up and running and simple builds, but long term I don’t trust node packages to continue to work from where I left off, and it is unnacceptable to me that to change a css rule somewhere five years from now, I may be left with days of work when revisiting a perfectly happy app. These requirements are not everyone’s requirements so to be clear, as implemented, tailwind and tailwind cli are great choices for many folks 
Wow, this opens a new gate for me! On the front-end, it’s a bit hard to do CSS tree-shaking if the HTML comes dynamically from the backend. But if the CSS is generated on the back-end, we can predict which CSS rules will never be used!
And the heex html engine could easily lift out class information so this kind of thing could work really nicely together.
