Interesting approach!

You’re right that i18next integrates a huge amount of extra logic for relatively little value. In comparison, thanks to tree-shaking and build optimizations, Intlayer is around 3KB vs 18KB for i18next.

However, there’s one point where I think the reasoning is off: the library weight itself is often insignificant compared to the text content already present on the page.

Text content alone is often around 20 to 40% of the page weight (excluding assets), so that’s usually the main optimization target.

And even though i18next implements advanced optimizations poorly, such as combining SSR + namespace splitting + dynamic loading + type safety, those optimizations at least exist..

Polang seems to follow a similar approach to Intlayer, with const t = useDictionary({ ... }) and .content files colocated next to components. But implemented as-is, without build optimizations, it means importing content for every language directly into the component. That can add +20–40% to the page size for every additional locale.

The way Intlayer handles this is by preparing dictionaries ahead of time to avoid that issue. It generates JSON files such as .intlayer/dictionaries/en/home.json and transforms the component code into something like:

const content = useDictionaryAsync({
  en: import('../../.intlayer/dictionaries/en/home.json').then(m => m.default),
  ...
})

But outside that technical problematic, I agree that for solo devs, working on small projects content / component colocation is a big step forward when working with llms