Rozwiązania do internacjonalizacji należą do najcięższych zależności w aplikacji Solid. Głównym ryzykiem jest wysyłanie niepotrzebnych treści: tłumaczeń dla innych stron i innych lokalizacji w paczce (bundle) pojedynczej trasy.

W miarę rozwoju aplikacji problem ten może szybko zwiększyć ilość JavaScriptu wysyłanego do klienta i spowolnić nawigację.

W praktyce, w przypadku najmniej zoptymalizowanych implementacji, strona zinternacjonalizowana może okazać się kilkukrotnie cięższa niż wersja bez i18n.

Innym skutkiem jest wpływ na doświadczenie programisty (DX): sposób deklarowania treści, typy, organizacja przestrzeni nazw (namespaces), dynamiczne ładowanie i reaktywność przy zmianie lokalizacji.

TL;DR

Intlayer: Zalecany wybór dla profesjonalnych aplikacji Solid wymagających zaawansowanych funkcji i optymalizacji (v8.7.12).
@solid-primitives/i18n: Doskonała lekka alternatywa dla prostych projektów, choć brakuje jej zaawansowanych funkcji, takich jak lazy loading.
solid-i18next: Standardowa, ale ciężka opcja (~4.7x Intlayer) z tymi samymi wadami co React i18next.
Paraglide: Innowacyjne podejście, ale złożone DX i problemy z tree-shakingiem w niektórych konfiguracjach.

Przetestuj swoją aplikację

Aby szybko wykryć problemy z wyciekami i18n, przygotowałem darmowy skaner dostępny tutaj.

intlayer.org

Problem

Dwa dźwignie są kluczowe dla ograniczenia kosztów aplikacji wielojęzycznej:

Dzielenie treści według stron / przestrzeni nazw, aby nie ładować całych słowników, gdy nie są potrzebne.
Dynamiczne ładowanie odpowiedniej lokalizacji tylko wtedy, gdy jest potrzebna.

Zrozumienie technicznych ograniczeń tych podejść:

Dynamiczne ładowanie

Bez dynamicznego ładowania większość rozwiązań przechowuje komunikaty w pamięci od pierwszego renderowania, co dodaje znaczny narzut w przypadku aplikacji z wieloma trasami i lokalizacjami.

Dzięki dynamicznemu ładowaniu akceptujesz kompromis: mniej początkowego JS, ale czasami dodatkowe zapytanie przy zmianie języka.

Dzielenie treści (Splitting)

Składnie zbudowane wokół t('a.b.c') są bardzo wygodne, ale często zachęcają do utrzymywania dużych obiektów JSON w czasie wykonywania. Ten model utrudnia tree-shaking, chyba że biblioteka oferuje rzeczywistą strategię dzielenia na poszczególne strony.

Metodologia badań

W tym benchmarku porównaliśmy następujące biblioteki:

Base App (Brak biblioteki i18n)
solid-intlayer (v8.7.12)
@solid-primitives/i18n (v2.2.1)
solid-i18next (v17.0.2)
@inlang/paraglide-js (v2.17.0)

Framework to Solid z aplikacją wielojęzyczną składającą się z 10 stron i 10 języków.

Porównaliśmy cztery strategie ładowania:

Pokaż całą zawartość tabeli

Otwórz tabelę w oknie modalnym, aby wyraźnie zobaczyć całą zawartość

Strategia	Brak przestrzeni nazw (globalna)	Z przestrzeniami nazw (scoped)
Ładowanie statyczne	Static: Wszystko w pamięci przy starcie.	Scoped static: Podział na przestrzenie nazw; wszystko ładowane przy starcie.
Ładowanie dynamiczne	Dynamic: Ładowanie na żądanie na lokalizację.	Scoped dynamic: Szczegółowe ładowanie na przestrzeń nazw i lokalizację.

Podsumowanie strategii

Static: Proste; brak opóźnień sieciowych po początkowym załadowaniu. Minus: duży rozmiar paczki.
Dynamic: Zmniejsza początkową wagę (lazy-loading). Idealne, gdy masz wiele lokalizacji.
Scoped static: Utrzymuje porządek w kodzie (logiczna separacja) bez skomplikowanych dodatkowych zapytań sieciowych.
Scoped dynamic: Najlepsze podejście dla code splittingu i wydajności. Minimalizuje zużycie pamięci, ładując tylko to, czego potrzebuje bieżący widok i aktywna lokalizacja.

Gwiazdki na GitHubie

Gwiazdki na GitHubie są silnym wskaźnikiem popularności projektu, zaufania społeczności i długoterminowego znaczenia. Choć nie są bezpośrednią miarą jakości technicznej, odzwierciedlają, ilu programistów uważa projekt za przydatny, śledzi jego postępy i prawdopodobnie go przyjmie. Przy szacowaniu wartości projektu gwiazdki pomagają porównać zainteresowanie alternatywami i dostarczają wglądu w rozwój ekosystemu.

Wyniki szczegółowe

1 - Rozwiązania, których należy unikać

W ekosystemie Solid nie ma jednoznacznego rozwiązania, którego należy unikać.

2 - Rozwiązania akceptowalne

(solid-i18next) (solid-i18next@17.0.2):

solid-i18next jest prawdopodobnie najpopularniejszą opcją, ponieważ był jednym z pierwszych rozwiązań zaspokajających potrzeby i18n aplikacji JavaScript. Posiada również szeroki zestaw wtyczek społecznościowych dla konkretnych problemów.

Paczka jest ciężka (~14.6kb, co stanowi około 4.7x solid-intlayer).

Mimo to dzieli te same główne wady co stosy technologiczne zbudowane na t('a.b.c'): optymalizacje są możliwe, ale bardzo czasochłonne, a duże projekty niosą ze sobą ryzyko złych praktyk (przestrzenie nazw + dynamiczne ładowanie + typy).

(@solid-primitives/i18n) (@solid-primitives/i18n@2.2.1):

Solid primitive jest niezwykle lekki i wydajny. Polecam to rozwiązanie dla lekkich projektów, ale może w nim szybko zabraknąć funkcji dla profesjonalnych rozwiązań, w tym zarządzania plikami cookie, przekierowań proxy, formaterów itp. Brakuje mu również lazy loadingu i scopingu przestrzeni nazw w celu optymalizacji rozmiaru strony.

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

Paraglide oferuje innowacyjne, przemyślane podejście. Mimo to w tym benchmarku reklamowany przez nich tree-shaking nie zadziałał w mojej implementacji. Workflow i DX są również bardziej złożone niż w przypadku innych opcji. Osobiście nie lubię konieczności regeneracji plików JS przed każdym pushem, co stwarza ciągłe ryzyko konfliktów przy mergowaniu poprzez PR-y. Wreszcie, w porównaniu z innymi rozwiązaniami, Paraglide nie używa store'a (np. Solid signal) do pobierania aktualnej lokalizacji w celu renderowania treści. Dla każdego sparsowanego węzła będzie żądać lokalizacji z localStorage / cookie itp. Prowadzi to do wykonywania niepotrzebnej logiki, która wpływa na reaktywność komponentu.

3 - Rekomendacje

(Intlayer) (solid-intlayer@8.7.12):

Nie będę osobiście oceniać solid-intlayer ze względu na obiektywizm, ponieważ jest to moje własne rozwiązanie.

Notatka osobista

Ta notatka jest osobista i nie wpływa na wyniki benchmarku. Mimo to w świecie i18n często widać konsensus wokół wzorca takiego jak const t = useTranslation('xx') + <>{t('xx.xx')}</> dla treści przetłumaczonych.

W aplikacjach Solid wstrzykiwanie funkcji jako JSX.Element jest moim zdaniem antywzorcem. Dodaje to również złożoność, której można uniknąć, oraz narzut na wykonywanie JavaScriptu (nawet jeśli jest on ledwo zauważalny).

Vue

Svelte