Over the last few years, we’ve started to see a new category of i18n tooling: compiler-based solutions. The compiler promises a kind of “magic” that makes your app multilingual with almost no effort. And to be fair, this compiler is trying to solve a very real problem: How do we avoid wasting time once we decide to make an app multilingual? I built a compiler to address what was the most requested feature, and I wanted to share some conclusions about this approach compared to traditional ones: What are the limits of this approach? What are the risks for your bundle size or runtime? When should you adopt (or avoid) this kind of solution? The reality is that the compiler does not bypass how browsers load and process JavaScript. Because of that, it often ends up being less optimized for your specific application than more traditional i18n approaches. However, a compiler-based approach does introduce an innovative workflow that significantly reduce the time spent managing translations, as well as the risk of bundle explosion.

The real opportunity is to understand where this “magic” genuinely adds value, and how those concept might influence the next generation of i18n tools