I may just be being pedantic here, but isn't this AOT rather than JIT? JIT means the optimizer is code that ships as part of the runtime, which is sort of the opposite of what this does.
I've started investigating whether a truly "just in time" variant of Tailwind is reasonable. It's almost like a CSS transpiler - converting tailwind classnames to their CSS form.
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.
Thing is, what they had before is also defined as AOT (of the build step) too. JIT here refers to the Just-In-Time for the build, not for the client. Saying it JIT is clearer in the context if Tailwind, but not in general.
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).
Deviation between build-time and run-time is...normal. The fact that JS is a dynamic language that doesn't necessarily require a build step, but we've introduced one anyways, doesn't really change the equation.
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.
Also worth mentioning that rebuilding on file system events is something that already existed in the JS space, and it's typically just called "watching". Even the compile-only-what-is-needed part already has established terminology (dead code elimination in the general case, and "tree-shaking" in the JS NIH case)
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.
