Solid i18n Kütüphaneleri - 2026 Benchmark Raporu

Bu sayfa, Solid üzerindeki i18n çözümleri için bir benchmark raporudur.

İçindekiler

İnteraktif Benchmark

Sonuç referansı:

Tam kıyaslama verilerini görün

Tüm benchmark deposunu burada görebilirsiniz.

Giriş

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.

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:

Strateji özeti

• Static: Basit; başlangıç yüklemesinden sonra ağ gecikmesi yok. Dezavantajı: büyük paket 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.

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) ([email protected]):

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/[email protected]):

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/[email protected]):

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) ([email protected]):

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