Библиотеки i18n для TanStack Start - Отчет о бенчмарке 2026

Эта страница представляет собой отчет о бенчмарке i18n-решений для TanStack Start.

Содержание

Интерактивный бенчмарк

Ссылка на результаты:

Посмотреть полные данные бенчмарка

Полный репозиторий бенчмарка можно найти здесь.

Введение

Решения для интернационализации являются одними из самых тяжелых зависимостей в React-приложении. В случае с TanStack Start основной риск заключается в передаче ненужного контента: переводов для других страниц и других локалей в бандле одного маршрута.

По мере роста вашего приложения эта проблема может быстро привести к раздуванию JavaScript, отправляемого клиенту, и замедлению навигации.

На практике в наименее оптимизированных реализациях интернационализированная страница может оказаться в несколько раз тяжелее версии без i18n.

Другой аспект - это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.

TL;DR

• Intlayer: Обеспечивает лучшую производительность и наименьший размер бандла (v8.7.12) для TanStack Start.
• react-i18next и use-intl: Зрелые альтернативы с большими экосистемами, но значительно тяжелее и сложнее в оптимизации.
• Paraglide: Инновационная идея tree-shaking, которая не работает на практике. Сложный DX и накладные расходы на реактивность в TanStack Start.
• Избегайте: General Translation (GT) и Lingo.dev из-за серьезных проблем с производительностью, лимитов AI и привязки к вендору (vendor lock-in).

Проверьте свое приложение

Чтобы быстро выявить проблемы с утечкой i18n, я настроил бесплатный сканер, доступный здесь.

Проблема

Два рычага необходимы для ограничения стоимости мультиязычного приложения:

• Разделение контента по страницам / пространствам имен, чтобы не загружать целые словари, когда они вам не нужны.
• Динамическая загрузка нужной локали только тогда, когда она требуется.

Понимание технических ограничений этих подходов:

Динамическая загрузка

Без динамической загрузки большинство решений хранят сообщения в памяти с первого рендеринга, что создает значительные накладные расходы для приложений с множеством маршрутов и локалей.

При использовании динамической загрузки вы идете на компромисс: меньше начального JS, но иногда дополнительный запрос при переключении языка.

Разделение контента

Синтаксис, построенный вокруг const t = useTranslation() + t('a.b.c'), очень удобен, но часто способствует хранению больших JSON-объектов во время выполнения. Эта модель затрудняет tree-shaking, если библиотека не предлагает реальную стратегию разделения контента для каждой страницы.

Методология

Для этого бенчмарка мы сравнили следующие библиотеки:

• Base App (Без библиотеки i18n)
• react-intlayer (v8.7.12)
• react-i18next (v17.0.2)
• use-intl (v4.9.1)
• @lingui/core (v5.3.0)
• @inlang/paraglide-js (v2.15.1)
• @tolgee/react (v7.0.0)
• react-intl (v10.1.1)
• wuchale (v0.22.11)
• gt-react (vlatest)
• lingo.dev (v0.133.9)

Фреймворк - TanStack Start с мультиязычным приложением из 10 страниц и 10 языков.

Мы сравнили четыре стратегии загрузки:

Резюме стратегий

• Статическая (Static): Простота; отсутствие задержек сети после начальной загрузки. Минус: большой размер бандла.
• Динамическая (Dynamic): Уменьшает начальный вес (ленивая загрузка). Идеально при наличии множества локалей.
• Локальная статическая (Scoped static): Позволяет организовать код (логическое разделение) без сложных дополнительных сетевых запросов.
• Локальная динамическая (Scoped dynamic): Лучший подход для разделения кода и производительности. Минимизирует использование памяти, загружая только то, что нужно для текущего представления и активной локали.

Звезды на GitHub

Звезды на GitHub - это сильный индикатор популярности проекта, доверия сообщества и долгосрочной актуальности. Хотя они не являются прямым показателем технического качества, они отражают, сколько разработчиков считают проект полезным, следят за его прогрессом и, вероятно, будут его использовать. Для оценки ценности проекта звезды помогают сравнивать популярность альтернатив и дают представление о росте экосистемы.

Результаты в деталях

1 - Решения, которых следует избегать

Некоторых решений, таких как gt-react или lingo.dev, явно стоит остерегаться. Они сочетают в себе привязку к вендору с загрязнением вашей кодовой базы. Хуже того: несмотря на многие часы попыток внедрить их, мне так и не удалось заставить их работать должным образом на TanStack Start (аналогично Next.js с gt-next).

Встреченные проблемы:

(General Translation) (gt-react@latest):

• Для приложения весом около 110 КБ gt-react может добавить более 440 КБ сверху (порядок величины, наблюдаемый в реализации Next.js в том же бенчмарке).
• Quota Exceeded, please upgrade your plan (Квота превышена, пожалуйста, обновите тарифный план) при самой первой сборке с General Translation.
• Переводы не отображаются; я получаю ошибку Error: <T> used on the client-side outside of <GTProvider>, что кажется багом библиотеки.
• При внедрении gt-tanstack-start-react я также столкнулся с проблемой в библиотеке: does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser, которая приводила к поломке приложения. После сообщения об этой проблеме сопровождающий исправил ее в течение 24 часов.
• Эти библиотеки используют антипаттерн через функцию initializeGT(), что мешает сборке чисто исключать неиспользуемый код (tree-shaking).

(Lingo.dev) ([email protected]):

• Квота AI превышена (или блокирующая зависимость от сервера), что делает сборку / продакшн рискованными без оплаты.
• Компилятор пропустил почти 40% переведенного контента. Мне пришлось переписать все вызовы .map в плоские блоки компонентов, чтобы это заработало.
• Их CLI работает с ошибками и периодически сбрасывает конфигурационный файл без причины.
• При сборке он полностью удалял сгенерированные JSON-файлы, когда добавлялся новый контент. В результате всего несколько ключей могли стереть сотни существующих.
• Я столкнулся с проблемами реактивности в этой библиотеке на TanStack Start: при смене локали мне приходилось принудительно перерендеривать провайдер.

2 - Экспериментальные решения

(Wuchale) ([email protected]):

Идея Wuchale интересна, но это пока не жизнеспособное решение. Я столкнулся с проблемами реактивности в этой библиотеке и был вынужден принудительно перерендеривать провайдер, чтобы приложение заработало на TanStack Start. Документация также довольно неясная, что затрудняет начало работы.

3 - Приемлемые решения

(Paraglide) (@inlang/[email protected]):

Paraglide предлагает инновационный, хорошо продуманный подход. Тем не менее, в этом бенчмарке обещанный tree-shaking не сработал ни для моей реализации на Next.js, ни для TanStack Start. Процесс работы и DX также сложнее, чем у других вариантов. Лично я не в восторге от необходимости перегенерировать JS-файлы перед каждым пушем, что создает постоянный риск конфликтов при слиянии в PR.

Примечание о paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате чего метрика 'размер библиотеки' в отчете бенчмарка практически равна 0. Генерация кода - это хорошо, потому что используемая функция будет включать только необходимую логику (полный префикс против отсутствия префикса, куки против хранилища и т. д.). Для сравнения, Intlayer выполняет эту фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить бандлер выполнять tree-shaking контента в зависимости от логики. Благодаря этому paraglide и intlayer в итоге оказываются в 6-10 раз легче, чем i18next или next-intl.

(Tolgee) (@tolgee/[email protected]):

Tolgee решает многие из упомянутых ранее проблем. Мне показалось, что начать работу с ним сложнее, чем с другими инструментами с похожими подходами. Он не обеспечивает типобезопасность, что значительно затрудняет отлов отсутствующих ключей на этапе компиляции. Мне пришлось обернуть API Tolgee своими собственными, чтобы добавить обнаружение отсутствующих ключей.

На TanStack Start у меня также были проблемы с реактивностью: при смене локали мне приходилось принудительно перерендеривать провайдер и подписываться на события смены локали, чтобы загрузка на другом языке вела себя корректно.

(use-intl) ([email protected]):

use-intl - самый модный представитель "intl" в экосистеме React (из того же семейства, что и next-intl), который часто продвигают AI-агенты, но, на мой взгляд, ошибочно в контексте производительности. Начать работу довольно просто. На практике процесс оптимизации и ограничения утечек довольно сложен. Аналогично, сочетание динамической загрузки + пространств имен + типов TypeScript сильно замедляет разработку.

На TanStack Start вы избегаете ловушек, специфичных для Next.js (setRequestLocale, статический рендеринг), но основная проблема та же: без строгой дисциплины бандл быстро переполняется сообщениями, а обслуживание пространств имен для каждого маршрута становится мучительным.

(react-i18next) ([email protected]):

react-i18next, вероятно, является самым популярным вариантом, так как был одним из первых решений для нужд i18n в JavaScript-приложениях. У него также есть широкий набор плагинов от сообщества для конкретных задач.

Тем не менее, у него те же основные недостатки, что и у стеков, построенных на t('a.b.c'): оптимизация возможна, но отнимает очень много времени, а большие проекты рискуют столкнуться с плохими практиками.

Форматы сообщений также расходятся: use-intl использует ICU MessageFormat, в то время как i18next использует свой собственный формат, что усложняет инструментарий или миграцию при их смешивании.

(Lingui) (@lingui/[email protected]):

Lingui часто хвалят. Лично мне рабочий процесс вокруг lingui extract / lingui compile показался более сложным, чем другие подходы, без явных преимуществ в этом бенчмарке TanStack Start. Я также заметил непоследовательный синтаксис, который путает AI (например, t(), t'', i18n.t(), <Trans>).

(react-intl) ([email protected]):

react-intl - это производительная реализация от команды Format.js. DX остается многословным: const intl = useIntl() + intl.formatMessage({ id: "xx.xx" }) добавляет сложности, лишней работы для JavaScript и привязывает глобальный экземппляр i18n ко многим узлам в дереве React.

4 - Рекомендации

В этом бенчмарке TanStack Start нет прямого эквивалента next-translate (плагин Next.js + getStaticProps). Для команд, которые действительно хотят API t() со зрелой экосистемой, react-i18next и use-intl остаются "разумным" выбором, но будьте готовы потратить много времени на оптимизацию, чтобы избежать утечек.

(Intlayer) ([email protected]):

Я не буду лично судить о react-intlayer ради объективности, так как это мое собственное решение.

Личное примечание

Это примечание является личным и не влияет на результаты бенчмарка. Тем не менее, в мире i18n часто можно встретить консенсус вокруг паттерна типа const t = useTranslation('xx') + <>{t('xx.xx')}</> для переведенного контента.

В React-приложениях внедрение функции в качестве ReactNode, на мой взгляд, является антипаттерном. Это также добавляет лишнюю сложность и накладные расходы на выполнение JavaScript (даже если это почти незаметно).