TanStack Start i18n लाइब्रेरीज़ - 2026 बेंचमार्क रिपोर्ट

यह पेज TanStack Start पर i18n समाधानों के लिए एक बेंचमार्क रिपोर्ट है।

विषय सूची

इंटरैक्टिव बेंचमार्क

परिणाम संदर्भ:

पूर्ण बेंचमार्क डेटा देखें

पूरा बेंचमार्क रिपॉजिटरी यहाँ देखें।

प्रस्तावना

अंतर्राष्ट्रीयकरण समाधान React ऐप में सबसे भारी निर्भरताओं में से एक हैं। TanStack Start पर मुख्य जोखिम अनावश्यक सामग्री को शिप करना है: एक ही रूट के बंडल में अन्य पेजों और अन्य लोकेल्स के अनुवाद शामिल होना।

जैसे-जैसे आपका ऐप बढ़ता है, वह समस्या क्लाइयंट को भेजे जाने वाले जावास्क्रिप्ट को तेज़ी से बढ़ा सकती है और नेविगेशन को धीमा कर सकती है।

व्यवहार में, कम से कम अनुकूलित कार्यान्वयनों के लिए, अंतर्राष्ट्रीयकृत पेज बिना i18n वाले वर्जन की तुलना में कई गुना भारी हो सकता है।

दूसरा प्रभाव डेवलपर अनुभव (DX) पर पड़ता है: आप सामग्री को कैसे घोषित करते हैं, टाइप्स, नेमस्पेस संगठन, डायनेमिक लोडिंग, और लोकेल बदलने पर रिएक्टिविटी।

TL;DR

• Intlayer: TanStack Start के लिए सर्वश्रेष्ठ प्रदर्शन और सबसे छोटा बंडल आकार (v8.7.12) प्रदान करता है।
• react-i18next और use-intl: बड़े ईकोसिस्टम वाले परिपक्व विकल्प, लेकिन अनुकूलन के लिए काफी भारी और अधिक जटिल।
• Paraglide: अभिनव ट्री-शेकिंग विचार जो व्यवहार में काम नहीं करता है। TanStack Start में जटिल DX और रिएक्टिविटी ओवरहेड।
• बचें: General Translation (GT) और Lingo.dev गंभीर प्रदर्शन समस्याओं, AI कोटा सीमाओं और वेंडर लॉक-इन (vendor lock-in) के कारण।

अपने ऐप का परीक्षण करें

i18n लीकेज के मुद्दों को तेज़ी से पहचानने के लिए, मैंने एक मुफ़्त स्कैनर सेट किया है जो यहाँ उपलब्ध है।

समस्या

मल्टीलिंगुअल ऐप की लागत को सीमित करने के लिए दो लीवर आवश्यक हैं:

• सामग्री को पेज / नेमस्पेस द्वारा विभाजित करें ताकि जब आपकी आवश्यकता न हो तो पूरे शब्दकोश लोड न हों।
• सही लोकेल को केवल आवश्यकता होने पर डायनेमिक रूप से लोड करें।

इन दृष्टिकोणों की तकनीकी सीमाओं को समझना:

डायनेमिक लोडिंग

डायनेमिक लोडिंग के बिना, अधिकांश समाधान पहले रेंडर से संदेशों को मेमोरी में रखते हैं, जो कई रूट्स और लोकेल्स वाले ऐप्स के लिए महत्वपूर्ण ओवरहेड जोड़ता है।

डायनेमिक लोडिंग के साथ, आप एक ट्रेड-ऑफ़ स्वीकार करते हैं: कम शुरुआती JS, लेकिन कभी-कभी भाषा बदलते समय एक अतिरिक्त अनुरोध।

कंटेंट स्प्लिटिंग (सामग्री विभाजन)

const t = useTranslation() + t('a.b.c') के इर्द-गिर्द बनी सिंटैक्स बहुत सुविधाजनक हैं लेकिन अक्सर रनटाइम पर बड़े JSON ऑब्जेक्ट रखने के लिए प्रोत्साहित करती हैं। वह मॉडल ट्री-शेकिंग को कठिन बना देता है जब तक कि लाइब्रेरी वास्तविक प्रति-पेज स्प्लिट रणनीति प्रदान न करे।

कार्यप्रणाली

इस बेंचमार्क के लिए, हमने निम्नलिखित लाइब्रेरीज़ की तुलना की है:

• 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)

फ़्रेमवर्क 10 पेजों और 10 भाषाओं के मल्टीलिंगुअल ऐप के साथ TanStack Start है।

हमने चार लोडिंग रणनीतियों की तुलना की:

रणनीतियों का सारांश

• Static: सरल; शुरुआती लोड के बाद कोई नेटवर्क लेटेंसी नहीं। नुकसान: बंडल का बड़ा आकार।
• Dynamic: शुरुआती वज़न कम करता है (लेज़ी-लोडिंग)। जब आपके पास कई लोकेल्स हों तो आदर्श है।
• Scoped static: अतिरिक्त जटिल नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित (लॉजिकल सेपरेशन) रखता है।
• Scoped dynamic: कोड स्प्लिटिंग और परफॉरमेंस के लिए सबसे अच्छा दृष्टिकोण। वर्तमान व्यू और सक्रिय लोकेल की आवश्यकता वाली चीज़ों को लोड करके मेमोरी को कम करता है।

मैंने क्या मापा:

मैंने हर स्टैक के लिए एक वास्तविक ब्राउज़र में एक ही बहुभाषी ऐप चलाया, फिर लिखा कि वास्तव में तार पर क्या दिखाई दिया और चीजों में कितना समय लगा। आकार सामान्य वेब कंप्रेशन के बाद रिपोर्ट किए जाते हैं, क्योंकि यह कच्चे स्रोत गणना की तुलना में लोग जो डाउनलोड करते हैं उसके करीब है।

• Internationalization लाइब्रेरी का आकार: bundling, tree-shaking और minification के बाद, i18n लाइब्रेरी का आकार providers (जैसे NextIntlClientProvider) + hooks (जैसे useTranslations) कोड का आकार एक खाली component में है। इसमें translation फाइलों का लोडिंग शामिल नहीं है। यह इस बात का उत्तर देता है कि आपकी content के picture में आने से पहले लाइब्रेरी कितनी महंगी है।

• प्रति पृष्ठ JavaScript: प्रत्येक benchmark route के लिए, ब्राउज़र उस visit के लिए कितनी script खींचता है, suite के pages में averaged (और locales में जहां report उन्हें roll करता है)। भारी pages धीमे pages हैं।

• अन्य locales से Leakage: यह एक ही page की content है लेकिन एक अलग language में जो audited page में गलती से लोड हो सकती है। यह content अनावश्यक है और इसे avoid किया जाना चाहिए। (उदाहरण के लिए /fr/about page content /en/about page bundle में)

• अन्य routes से Leakage: अन्य screens के लिए भी यही विचार है: क्या जब आप केवल एक page खोलते हैं तो उनकी copy साथ चल रही है। (उदाहरण के लिए /en/about page content /en/contact page bundle में)। एक high score कमजोर splitting या over-broad bundles का संकेत देता है।

• औसत component bundle का आकार: Common UI pieces को एक बार में एक मापा जाता है, एक विशाल app संख्या के अंदर छिपने के बजाय। यह दिखाता है कि क्या internationalization quietly रोज़मर्रा के components को inflate करती है। उदाहरण के लिए, यदि आपका component rerenders, तो यह memory से सभी data को load करेगा। किसी component को एक विशाल JSON को attach करना अप्रयुक्त data के एक बड़े store को जोड़ने जैसा है जो आपके components के performance को धीमा कर देगा।

• Language switch responsiveness: मैं ऐप के अपने control का उपयोग करके language को flip करता हूं और time करता हूं कि page clearly switch होने में कितना समय लगता है, जो एक visitor को notice होगा, एक lab micro-step नहीं।

• Language change के बाद Rendering work: एक narrower follow-up: interface को repaint करने में कितना effort लगा नई language के लिए एक बार switch flight में है। उपयोगी जब "felt" time और framework cost diverge हों।

• Initial page load time: Navigation से browser तक यह मानते हुए कि मैंने जिन scenarios को test किया उनके लिए page पूरी तरह से loaded है। Cold starts की तुलना करने के लिए अच्छा है।

• Hydration time: जब ऐप इसे expose करता है, तो client कितना समय server HTML को ऐसी चीज़ में बदलने में खर्च करता है जिस पर आप actually क्लिक कर सकते हैं। Tables में एक dash का मतलब है कि implementation ने इस benchmark में एक reliable hydration figure प्रदान नहीं किया।

GitHub सितारे

GitHub सितारे किसी प्रोजेक्ट की लोकप्रियता, सामुदायिक विश्वास और दीर्घकालिक प्रासंगिकता का एक मजबूत संकेतक हैं। हालांकि यह तकनीकी गुणवत्ता का प्रत्यक्ष माप नहीं है, वे दर्शाते हैं कि कितने डेवलपर्स प्रोजेक्ट को उपयोगी पाते हैं, इसकी प्रगति का पालन करते हैं, और इसे अपनाने की संभावना रखते हैं। किसी प्रोजेक्ट के मूल्य का अनुमान लगाने के लिए, सितारे विकल्पों के बीच कर्षण की तुलना करने में मदद करते हैं और पारिस्थितिकी तंत्र के विकास में अंतर्दृष्टि प्रदान करते हैं।

परिणाम विस्तार से

1 - बचने के लिए समाधान

gt-react या lingo.dev जैसे कुछ समाधान स्पष्ट रूप से ऐसे हैं जिनसे दूर रहना चाहिए। वे वेंडर लॉक-इन को आपके कोडबेस को प्रदूषित करने के साथ जोड़ते हैं। इससे भी बदतर: उन्हें लागू करने की कोशिश में कई घंटे बिताने के बावजूद, मैंने उन्हें TanStack Start पर कभी ठीक से काम करते हुए नहीं पाया (Next.js पर gt-next के समान) ।

सामना किए गए मुद्दे:

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

• लगभग 110kb के ऐप के लिए, gt-react 440kb से अधिक अतिरिक्त डेटा जोड़ सकता है (इसी बेंचमार्क में Next.js कार्यान्वयन पर देखा गया परिमाण)।
• जनरल ट्रांसलेशन के साथ पहले ही बिल्ड पर Quota Exceeded, please upgrade your plan संदेश।
• अनुवाद रेंडर नहीं होते हैं; मुझे एरर मिलता है 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() फ़ंक्शन के माध्यम से एक एंटी-पैटर्न का उपयोग करती हैं, जिससे बंडल को साफ़-सुथरे ढंग से ट्री-शेकिंग करने से रोका जाता है।

(Lingo.dev) (lingo.dev@0.133.9):

• AI कोटा समाप्त हो गया (या सर्वर निर्भरता को अवरुद्ध करना), जिससे भुगतान के बिना बिल्ड / प्रोडक्शन जोखिम भरा हो गया।
• कंपाइलर अनुवादित सामग्री के लगभग 40% को मिस कर रहा था। मुझे इसे काम कराने के लिए सभी .map को फ्लैट कंपोनेंट ब्लॉक्स में दोबारा लिखना पड़ा।
• उनका CLI काफी बग्स वाला है और बिना किसी कारण के कॉन्फ़िगरेशन फ़ाइल को रीसेट कर देता था।
• बिल्ड के समय, नई सामग्री जोड़ने पर इसने जेनरेट किए गए JSON को पूरी तरह से मिटा दिया। परिणामस्वरूप, आप समाप्त कर सकते हैं कि केवल कुछ कीज़ सैकड़ों मौजूदा कीज़ को मिटा रही हैं।
• मुझे TanStack Start पर लाइब्रेरी के साथ रिएक्टिविटी के मुद्दों का सामना करना पड़ा: लोकेल बदलने पर मुझे इसे काम कराने के लिए प्रोवाइडर के फोर्स री-रेंडर की आवश्यकता थी।

2 - प्रयोगात्मक समाधान

(Wuchale) (wuchale@0.22.11):

Wuchale के पीछे का विचार दिलचस्प है लेकिन अभी तक व्यवहार्य समाधान नहीं है। मुझे लाइब्रेरी के साथ रिएक्टिविटी के मुद्दों का सामना करना पड़ा और TanStack Start पर ऐप को काम कराने के लिए प्रोवाइडर के फोर्स री-रेंडर की आवश्यकता थी। दस्तावेज़ीकरण भी काफी अस्पष्ट है, जिससे ऑनबोर्डिंग कठिन हो जाती है।

3 - स्वीकार्य समाधान

(Paraglide) (@inlang/paraglide-js@2.15.1):

Paraglide एक अभिनव, अच्छी तरह से सोचा गया दृष्टिकोण प्रदान करता है। फिर भी, इस बेंचमार्क में उनकी कंपनी द्वारा विज्ञापित ट्री-शेकिंग मेरे Next.js कार्यान्वयन या TanStack Start के लिए काम नहीं कर पाया। वर्कफ़्लो और DX अन्य विकल्पों की तुलना में अधिक जटिल हैं। व्यक्तिगत रूप से मैं हर पुश से पहले JS फ़ाइलों को दोबारा उत्पन्न करने का प्रशंसक नहीं हूँ, जो PR के माध्यम से डेवलपर्स के लिए लगातार मर्ज संघर्ष का जोखिम पैदा करता है।

paraglide पर नोट: यह समाधान आयात के लिए आपके कोडबेस में कोड इंजेक्ट करता है, जिसके परिणामस्वरूप बेंचमार्क रिपोर्ट में 'lib size' मीट्रिक लगभग 0 है। कोड जनरेशन एक अच्छी चीज़ है, क्योंकि उपयोग किया गया फ़ंक्शन केवल आवश्यक लॉजिक (हर जगह प्रीफ़िक्स बनाम कोई प्रीफ़िक्स नहीं, कुकी बनाम स्टोरेज, आदि) शामिल करेगा। इसके विपरीत, Intlayer बिल्ड में एनवायरनमेंट वेरिएबल इंजेक्शन के माध्यम से यह फ़िल्टरिंग करता है ताकि बंडलर को लॉजिक के आधार पर सामग्री को ट्री-शेक करने के लिए मजबूर किया जा सके। इसके लिए धन्यवाद, paraglide और intlayer अंत में i18next या next-intl की तुलना में 6 से 10 गुना हल्के समाधान बन जाते हैं।

(Tolgee) (@tolgee/react@7.0.0):

Tolgee पहले उल्लेखित कई मुद्दों को संबोधित करता है। मुझे लगा कि इसे शुरू करना समान दृष्टिकोण वाले अन्य उपकरणों की तुलना में कठिन है। यह टाइप सेफ्टी प्रदान नहीं करता है, जिससे कंपाइल समय पर गायब कीज़ को पकड़ना भी बहुत कठिन हो जाता है। गायब-की पहचान जोड़ने के लिए मुझे Tolgee की APIs को अपनी APIs के साथ रैप करना पड़ा।

पैकेज काफी भारी है (~11.1kb, जो react-intlayer से 2× अधिक है)।

TanStack Start पर मुझे रिएक्टिविटी की समस्याएं भी थीं: लोकेल बदलने पर, मुझे प्रोवाइडर को री-रेंडर करने के लिए मजबूर करना पड़ा और लोकेल-चेंज इवेंट्स को सब्सक्राइब करना पड़ा ताकि दूसरी भाषा में लोडिंग सही ढंग से व्यवहार करे।

(use-intl) (use-intl@4.9.1):

use-intl वर्तमान में React ईकोसिस्टम में सबसे ट्रेंडी "intl" पीस है ( next-intl के समान परिवार) और इसे अक्सर AI एजेंटों द्वारा पुश किया जाता है, लेकिन मेरी दृष्टि में परफॉरमेंस-फ़र्स्ट सेटिंग में गलत तरीके से। शुरुआत करना काफी सरल है। व्यवहार में, लीकेज को अनुकूलित और सीमित करने की प्रक्रिया काफी जटिल है। इसी प्रकार, डायनेमिक लोडिंग + नेमस्पेसिंग + TypeScript टाइप्स को जोड़ना विकास को बहुत धीमा कर देता है।

TanStack Start पर आप Next.js-विशिष्ट जाल ( setRequestLocale, स्टेटिक रेंडरिंग) से बचते हैं, लेकिन मुख्य मुद्दा वही है: सख्त अनुशासन के बिना, बंडल जल्दी से बहुत अधिक संदेशों को ढोता है और प्रति-रूट नेमस्पेस रखरखाव कष्टदायक हो जाता है।

(react-i18next) (react-i18next@17.0.2):

react-i18next शायद सबसे लोकप्रिय विकल्प है क्योंकि यह जावास्क्रिप्ट ऐप i18n आवश्यकताओं को पूरा करने वाले शुरुआती समाधानों में से एक था। इसमें विशिष्ट मुद्दों के लिए कम्युनिटी प्लगइन्स का एक विस्तृत सेट भी है।

फिर भी, यह t('a.b.c') पर बने स्टैक्स जैसी ही प्रमुख कमियाँ साझा करता है: अनुकूलन संभव है लेकिन बहुत समय लेने वाला है, और बड़ी परियोजनाओं में खराब प्रथाओं (नेमस्पेस + डायनेमिक लोडिंग + टाइप्स) में गिरने का जोखिम होता है।

पैकेज विशेष रूप से भारी है (~17.3kb, जो react-intlayer का लगभग 3.5× है)।

मैसेज फॉर्मेट्स भी भिन्न हैं: use-intl ICU MessageFormat का उपयोग करता है, जबकि i18next अपने स्वयं के फॉर्मेट का उपयोग करता है-जो टूल्स या माइग्रेशन को जटिल बनाता है यदि आप उन्हें मिलाते हैं।

(Lingui) (@lingui/core@5.3.0):

Lingui की अक्सर प्रशंसा की जाती है। व्यक्तिगत रूप से मुझे lingui extract / lingui compile वर्कफ़्लो अन्य दृष्टिकोणों की तुलना में अधिक जटिल लगा, इस TanStack Start बेंचमार्क में किसी स्पष्ट लाभ के बिना। मैंने असंगत सिंटैक्स भी देखे जो AI को भ्रमित करते हैं (उदा. t(), t'', i18n.t(), <Trans>) ।

(react-intl) (react-intl@10.1.1):

react-intl Format.js टीम का एक परफॉरमेंट कार्यान्वयन है। DX वर्बोस (verbose) रहता है: const intl = useIntl() + intl.formatMessage({ id: "xx.xx" }) जटिलता, अतिरिक्त जावास्क्रिप्ट कार्य जोड़ता है और ग्लोबल i18n इंस्टेंस को React ट्री के कई नोड्स से जोड़ता है।

पैकेज भी भारी है (~14.4kb, जो react-intlayer का लगभग 3× है)।

4 - सिफारिशें

इस TanStack Start बेंचमार्क का next-translate (Next.js प्लगइन + getStaticProps) के बराबर कोई सीधा विकल्प नहीं है। उन टीमों के लिए जो वास्तव में परिपक्व ईकोसिस्टम वाली t() API चाहती हैं, react-i18next और use-intl "उचित" विकल्प बने हुए हैं, लेकिन लीकेज से बचने के लिए अनुकूलन में बहुत समय निवेश करने के लिए तैयार रहें।

(Intlayer) (react-intlayer@8.7.12):

निष्पक्षता के लिए मैं व्यक्तिगत रूप से मेरे स्वयं के समाधान react-intlayer पर निर्णय नहीं दूँगा।

व्यक्तिगत राय

यह राय व्यक्तिगत है और बेंचमार्क परिणामों को प्रभावित नहीं करती है। फिर भी, i18n की दुनिया में, अक्सर अनुवादित सामग्री के लिए const t = useTranslation('xx') + <>{t('xx.xx')}</> जैसे पैटर्न के आसपास सहमति दिखती है।

React ऐप्स में, किसी फ़ंक्शन को ReactNode के रूप में इंजेक्ट करना, मेरी राय में, एक एंटी-पैटर्न है। यह टाली जा सकने वाली जटिलता और जावास्क्रिप्ट निष्पादन ओवरहेड (भले ही वह मुश्किल से ध्यान देने योग्य हो) को भी जोड़ता है।