You'll probably always want AOT for the "critical css" in the first load, but afterward, JIT might be reasonable.
At a minimum, it should be feasible. You can override Prototype's appendChild, replaceChild, and insertBefore to grab classnames and generate CSS before the DOM is updated. Everyone will tell you this is insane, but it seems to work.
But it's unclear if this leads to something "better" than the AOT solution. It feels like code golf: will the transpiler have less bytes than the CSS generated by a pure AOT solution? The tailwind folks have come up with a really dense way of expressing verbose CSS, so I think it's possible!
No affiliation to Tailwind. Just playing on weekends.
This is one of the reasons FE JS ecosystem is confusing as this also happens with the code (ex: process.env for environment variables only exists in the build step, not in the browser, but the code is mingled in the same file).
It's still exactly the same problem as building a C codebase versus running it.
The reason the FE JS ecosystem is confusing is because there's this absurd pretense that they're doing something novel whenever they implement a feature or tooling that has existed for decades (just not for JS). And then, because its novel, they come up with new names (or misuse old names, like here) because they either intentionally or unintentionally avoid using the 1:1 mapping with standard tooling.
Just-In-Time for the build just doesn't make sense -- a JIT is a very specific thing; it compiles code at runtime. The term exists specifically to differentiate from compilation at build-time. If you make a JIT for build-time, you've lost all meaning
This is just rebuilding the code more often... through a filewatcher.
Tailwind clearly is trying to put some effort into marketing, but IMHO misusing established terms like this can backfire in the sense that it makes them look like they're out of their depth wrt compilation literature.