aypineau

I'm really skeptical about this rewrite I chose to adopt bun about a year ago, and I've honestly lost count of the number of issues i've submitted and the amount of time i've wasted dealing with them. If I had to make the choice again, I would probably stick with node and pnpm for serious projects We're constantly being sold on promises of -XX% ram usage, but in practice, it's often builds randomly failing for no apparent reason, memory leaks bringing applications down, and instability that ends up costing far more in engineering time than the resources saved That's why i'm worried that bun 1.4 could end up being a step backwards, once again putting into question the small amount of stability we've managed to achieve so far

But I still strongly believe the project makes a lot of sense, and I genuinely think these issues can be solved by 2028, if the project keeps its focus on stability instead of another SDK for SQL, web sockets, image compression, or whatever comes next

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

It is surprisingly common to see developers hitting a wall with i18next. While it is a powerful internationalization framework, the learning curve is steeper than most admit.

Because AI tools like ChatGPT almost always recommend i18next as the default standard, many developers get lulled into a false sense of security by basic "get started" tutorials. They get it running, but is it actually production-ready?

Frequently, I see that SEO being completely overlooked. Things like localized metadata, proper Hreflang tags, link adaptation, and multilingual sitemaps are often missing.

Even more concerning is the performance hit. Since the AI boom, countless projects fail to utilize namespaces, accidentally bundling every translation string into a single payload. This means a user visiting one page is forced to download the text for every page in every language-resulting in a massive amount of dead code (often upwards of 50%). If you run a bundle analyzer, you’ll likely see the damage.

To fix this, I’ve put together a comprehensive walkthrough on architecting a Next.js 16 application with i18next properly for 2025.

I see people struggling with i18next far too often. And indeed, it is an internationalization technology that can be complicated to pick up.

Despite this, i18next is the default solution ChatGPT suggests for your i18n. We often get tricked by "Get Started" pages (sure, it works, but is it actually done well?).

In practice, I see many projects skipping the most critical parts of internationalization, specifically SEO: Translating metadata, Hreflang tags, Link localization, Sitemaps and robot.txt handling

Even worse, nearly half of the projects using i18next (especially since the rise of AI) don't manage their content in namespaces or load all namespaces on every request.

The impact is that you might be forcing every user to load the content of all pages in all languages just to view a single page. For example: with 10 pages in 10 languages, that’s 99% of loaded content that is never even accessed). Advice: use a bundle analyser to detect it.

To solve this, I have a guide on how to properly internationalize a Next.js 16 app with i18next in 2025.

Let me know your thoughts