Uluslararasılaştırma çözümleri, bir Solid uygulamasındaki en ağır bağımlılıklar arasındadır. Ana risk, gereksiz içerik göndermektir: tek bir rota paketinde diğer sayfalar ve diğer diller için çeviriler.

Uygulamanız büyüdükçe, bu sorun istemciye gönderilen JavaScript'i hızla büyütebilir ve navigasyonu yavaşlatabilir.

Pratikte, en az optimize edilmiş uygulamalar için, uluslararasılaştırılmış bir sayfa i18n olmayan sürümden birkaç kat daha ağır olabilir.

Diğer etki geliştirici deneyimi (DX) üzerindedir: içeriği nasıl tanımladığınız, tipler, namespace organizasyonu, dinamik yükleme ve dil değiştiğinde reaktivite.

TL;DR

Intlayer: Gelişmiş özelliklere ve optimizasyona ihtiyaç duyan profesyonel Solid uygulamaları için önerilen seçim (v8.7.12).
@solid-primitives/i18n: Basit projeler için mükemmel hafif bir alternatif, ancak lazy loading gibi gelişmiş özelliklerden yoksundur.
solid-i18next: Standart ancak ağır bir seçenek (~4.7x Intlayer), React i18next ile aynı dezavantajlara sahiptir.
Paraglide: Yenilikçi yaklaşım ancak karmaşık DX ve bazı kurulumlarda tree-shaking sorunları.

Uygulamanızı test edin

i18n sızıntı sorunlarını hızlıca tespit etmek için burada mevcut olan ücretsiz bir tarayıcı kurdum.

intlayer.org

Sorun

Çok dilli bir uygulamanın maliyetini sınırlamak için iki kaldıraç esastır:

İçeriği sayfa / namespace bazında bölün, böylece ihtiyacınız olmadığında tüm sözlükleri yüklemezsiniz.
Doğru dili dinamik olarak, yalnızca gerektiğinde yükleyin.

Bu yaklaşımların teknik sınırlarını anlamak:

Dinamik yükleme

Dinamik yükleme olmadan, çoğu çözüm mesajları ilk render'dan itibaren bellekte tutar ve bu da birçok rota ve dile sahip uygulamalar için önemli bir yük ekler.

Dinamik yükleme ile bir ödünleşimi kabul edersiniz: daha az başlangıç JS'i, ancak bazen dil değiştirirken ek bir istek.

İçerik bölme (Splitting)

t('a.b.c') etrafında inşa edilen söz dizimleri çok kullanışlıdır ancak genellikle çalışma zamanında büyük JSON nesnelerini tutmayı teşvik eder. Bu model, kütüphane sayfa başına gerçek bir bölme stratejisi sunmadıkça tree-shaking'i zorlaştırır.

Araştırma Metodolojisi

Bu benchmark için aşağıdaki kütüphaneleri karşılaştırdık:

Base App (i18n kütüphanesi yok)
solid-intlayer (v8.7.12)
@solid-primitives/i18n (v2.2.1)
solid-i18next (v17.0.2)
@inlang/paraglide-js (v2.17.0)

Framework, 10 sayfa ve 10 dilden oluşan çok dilli bir uygulamaya sahip Solid'dir.

Dört yükleme stratejisini karşılaştırdık:

Tüm tablo içeriğini göster

Tüm veri içeriğini net bir şekilde görmek için tabloyu modalde açın

Strateji	Namespace yok (global)	Namespace var (kapsamlı/scoped)
Statik yükleme	Static: Başlangıçta her şey bellekte.	Scoped static: Namespace'e göre bölünmüş; başlangıçta her şey yüklü.
Dinamik yükleme	Dynamic: Dil başına istek üzerine yükleme.	Scoped dynamic: Namespace ve dil başına hassas yükleme.

Strateji özeti

Static: Basit; başlangıç yüklemesinden sonra ağ gecikmesi yok. Dezavantajı: büyük bundle boyutu.
Dynamic: Başlangıç ağırlığını azaltır (lazy-loading). Birçok diliniz olduğunda idealdir.
Scoped static: Karmaşık ek ağ istekleri olmadan kodu düzenli tutar (mantıksal ayrım).
Scoped dynamic: Kod bölme ve performans için en iyi yaklaşım. Yalnızca geçerli görünüm ve aktif dil için gerekenleri yükleyerek belleği minimize eder.

Ölçtüklerim:

Aynı çok dilli uygulamayı her stack için gerçek bir tarayıcıda çalıştırdım, ardından tel üzerinde tam olarak ne göründüğünü ve işlerin ne kadar sürdüğünü not ettim. Boyutlar normal web sıkıştırmasından sonra rapor edilir, çünkü bu ham kaynak sayılarından daha çok insanların indirdiklerine yakındır.

Internationalization kütüphanesi boyutu: Bundling, tree-shaking ve minification işleminden sonra, i18n kütüphanesinin boyutu, boş bir bileşendeki sağlayıcılar + hooks/primitives kodunun boyutudur. Çeviri dosyalarının yüklenmesini içermez. Kütüphanenin içeriğiniz devreye girmeden önceki maliyetinin ne olduğunu yanıtlar.
Sayfa başına JavaScript: Her benchmark rotası için, tarayıcının bu ziyaret için çektiği betik miktarı, paketteki sayfalar (ve rapor onları topladığında yerel ayarlar) arasında ortalanmıştır. Ağır sayfalar yavaş sayfalardır.
Diğer yerel ayarlardan sızıntı: Denetlenen sayfada yanlışlıkla yüklenebilecek başka bir dilde aynı sayfanın içeriğidir. Bu içerik gereksizdir ve kaçınılmalıdır. (ör. /fr/about sayfa içeriği /en/about sayfa paketinde)
Diğer rotalardan sızıntı: Aynı fikir uygulamadaki diğer ekranlar için: sadece bir sayfayı açarken kopyalarının birlikte gidip gitmediği. (ör. /en/about sayfa içeriği /en/contact sayfa paketinde). Yüksek bir skor zayıf bölme veya çok geniş paketler hinting.
Ortalama bileşen paketi boyutu: Ortak UI parçaları birer birer ölçülür, bir dev app numarasının içinde gizlenmek yerine. Internationalization'ın sessizce günlük bileşenleri şişirip şişirmediğini gösterir. Örneğin, bileşeniniz yeniden render edilirse, bellekten tüm bu verileri yükleyecektir. Herhangi bir bileşene bir dev JSON bağlamak, bileşenlerinizin performansını yavaşlatacak kullanılmayan verilerin büyük bir deposunu bağlamak gibidir.
Dil değiştirme duyarlılığı: Uygulamanın kendi kontrolünü kullanarak dili çeviririm ve sayfanın açıkça değiştiği, bir ziyaretçinin fark edeceği, laboratuvar mikro adımı değil ne kadar sürdüğünü ölçerim.
Dil değişikliğinden sonraki işleme çalışması: Dar bir takip: arayüzün geçiş uçuşta iken yeni dil için yeniden boyamak için ne kadar çaba gerektiği. "Hissedilen" zaman ve çerçeve maliyeti farklılık gösterdiğinde yararlı.
İlk sayfa yükleme zamanı: Tarayıcının test ettiğim senaryolar için sayfayı tamamen yüklenmiş olarak görene kadar navigasyon. Soğuk başlangıçları karşılaştırmak için iyi.
Rehidrasyon zamanı: Uygulama bunu gösterdiğinde, istemcinin sunucu HTML'sini gerçekten tıklayabileceğiniz bir şeye dönüştürmek için harcadığı zaman. Tablolardaki bir çizgi, bu uygulamanın bu benchmark'ta güvenilir bir rehidrasyon şekli sağlamadığı anlamına gelir.

GitHub Yıldızları

GitHub yıldızları, bir projenin popülerliğinin, topluluk güveninin ve uzun vadeli alakasının güçlü bir göstergesidir. Teknik kalitenin doğrudan bir ölçüsü olmasa da, kaç geliştiricinin projeyi yararlı bulduğunu, ilerlemesini takip ettiğini ve benimseme olasılığını yansıtır. Bir projenin değerini tahmin etmek için yıldızlar, alternatifler arasındaki çekişi karşılaştırmaya yardımcı olur ve ekosistem büyümesi hakkında içgörüler sağlar.

Detaylı sonuçlar

1 - Kaçınılması gereken çözümler

Solid ekosisteminde kaçınılması gereken net bir çözüm yoktur.

2 - Kabul edilebilir çözümler

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

solid-i18next muhtemelen en popüler seçenektir çünkü JavaScript uygulaması i18n ihtiyaçlarını karşılayan ilklerden biriydi. Ayrıca belirli sorunlar için geniş bir topluluk eklentisi setine sahiptir.

Paket ağırdır (~14.6kb, bu da solid-intlayer'ın yaklaşık 4.7 katıdır).

Yine de, t('a.b.c') üzerine kurulu yığınlarla aynı ana dezavantajları paylaşır: optimizasyonlar mümkündür ancak çok zaman alıcıdır ve büyük projeler kötü uygulamalar (namespace + dinamik yükleme + tipler) riskiyle karşı karşıyadır.

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

Solid primitive son derece hafif ve verimlidir. Bu çözümü hafif projeler için öneriyorum, ancak çerez yönetimi, proxy yönlendirme, formatlayıcılar vb. dahil profesyonel çözümler için özellikleri hızla yetersiz kalabilir. Ayrıca sayfa boyutu optimizasyonu için lazy loading ve kapsamlı namespace özellikleri de eksiktir.

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

Paraglide yenilikçi ve iyi düşünülmüş bir yaklaşım sunuyor. Buna rağmen, bu benchmark'ta şirketlerinin reklamını yaptığı tree-shaking benim uygulamam için çalışmadı. İş akışı ve DX de diğer seçeneklerden daha karmaşıktır. Kişisel olarak her push'tan önce JS dosyalarını yeniden oluşturmak zorunda kalmayı sevmiyorum, bu da PR'lar aracılığıyla sürekli bir birleştirme çakışması riski yaratıyor. Son olarak, diğer çözümlerle karşılaştırıldığında Paraglide, içeriği işlemek için geçerli dili almak için bir store (örneğin Solid signal) kullanmaz. Ayrıştırılan her düğüm için localStorage / cookie vb.'den dili isteyecektir. Bu, bileşen reaktivitesini etkileyen gereksiz mantık yürütülmesine yol açar.

3 - Öneriler

(Intlayer) (solid-intlayer@8.7.12):

Kendi çözümüm olduğu için tarafsızlık adına solid-intlayer'ı kişisel olarak yargılamayacağım.

Kişisel not

Bu not kişiseldir ve benchmark sonuçlarını etkilemez. Yine de, i18n dünyasında çevrilmiş içerik için genellikle const t = useTranslation('xx') + <>{t('xx.xx')}</> gibi bir desen etrafında fikir birliği görürsünüz.

Solid uygulamalarında, bir fonksiyonu JSX.Element olarak enjekte etmek benim görüşüme göre bir anti-desendir. Ayrıca kaçınılabilir bir karmaşıklık ve JavaScript yürütme yükü ekler (zar zor fark edilse bile).

Vue

Svelte