Solid i18n-Bibliotheken - Benchmark-Bericht 2026

Diese Seite ist ein Benchmark-Bericht für i18n-Lösungen in Solid.

Inhaltsverzeichnis

Interaktiver Benchmark

Ergebnisreferenz:

Vollständige Benchmark-Daten anzeigen

Das vollständige Benchmark-Repository finden Sie hier.

Einleitung

Internationalisierungslösungen gehören zu den schwersten Abhängigkeiten in einer Solid-App. Das Hauptrisiko besteht darin, unnötige Inhalte zu versenden: Übersetzungen für andere Seiten und andere Sprachen im Bundle einer einzigen Route.

Wenn Ihre App wächst, kann dieses Problem die an den Client gesendeten JavaScript-Mengen schnell explodieren lassen und die Navigation verlangsamen.

In der Praxis kann eine internationalisierte Seite bei am wenigsten optimierten Implementierungen am Ende mehrmals schwerer sein als die Version ohne i18n.

Die andere Auswirkung betrifft die Entwicklererfahrung (DX): Wie Sie Inhalte deklarieren, Typen, Namespace-Organisation, dynamisches Laden und Reaktivität bei Sprachwechseln.

TL;DR

• Intlayer: Empfohlene Wahl für professionelle Solid-Anwendungen, die erweiterte Funktionen und Optimierung benötigen (v8.7.12).
• @solid-primitives/i18n: Exzellente leichtgewichtige Alternative für einfache Projekte, obwohl es an erweiterten Funktionen wie Lazy-Loading mangelt.
• solid-i18next: Standardmäßige, aber schwere Option (~4,7x Intlayer) mit den gleichen Nachteilen wie React i18next.
• Paraglide: Innovativer Ansatz, aber komplexe DX und Tree-Shaking-Probleme in einigen Setups.

Testen Sie Ihre App

Um i18n-Leakage-Probleme schnell zu erkennen, habe ich einen kostenlosen Scanner eingerichtet, der hier verfügbar ist.

Das Problem

Zwei Hebel sind wesentlich, um die Kosten einer mehrsprachigen App zu begrenzen:

• Inhalte nach Seite / Namespace aufteilen, damit Sie keine ganzen Wörterbücher laden, wenn Sie sie nicht benötigen.
• Das richtige Gebietsschema (Locale) dynamisch laden, nur wenn es benötigt wird.

Verständnis der technischen Einschränkungen dieser Ansätze:

Dynamisches Laden

Ohne dynamisches Laden halten die meisten Lösungen Nachrichten ab dem ersten Rendern im Speicher, was für Apps mit vielen Routen und Locales einen erheblichen Overhead bedeutet.

Mit dynamischem Laden akzeptieren Sie einen Kompromiss: weniger initiales JS, aber manchmal eine zusätzliche Anfrage beim Sprachwechsel.

Inhaltsaufteilung (Splitting)

Syntaxen, die um t('a.b.c') herum aufgebaut sind, sind sehr bequem, fördern aber oft das Beibehalten großer JSON-Objekte zur Laufzeit. Dieses Modell erschwert Tree-Shaking, es sei denn, die Bibliothek bietet eine echte Aufteilungsstrategie pro Seite.

Methodik

Für diesen Benchmark haben wir die folgenden Bibliotheken verglichen:

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

Das Framework ist Solid mit einer mehrsprachigen App aus 10 Seiten und 10 Sprachen.

Wir haben vier Ladestrategien verglichen:

Zusammenfassung der Strategien

• Static: Einfach; keine Netzwerklatenz nach dem ersten Laden. Nachteil: große Bundle-Größe.
• Dynamic: Reduziert das Anfangsgewicht (Lazy-Loading). Ideal, wenn Sie viele Locales haben.
• Scoped static: Hält den Code organisiert (logische Trennung) ohne komplexe zusätzliche Netzwerkanfragen.
• Scoped dynamic: Bester Ansatz für Code-Splitting und Leistung. Minimiert den Speicherverbrauch, indem nur das geladen wird, was die aktuelle Ansicht und die aktive Locale benötigen.

GitHub-Sterne

GitHub-Sterne sind ein starker Indikator für die Popularität eines Projekts, das Vertrauen der Community und die langfristige Relevanz. Sie sind zwar kein direktes Maß für die technische Qualität, spiegeln jedoch wider, wie viele Entwickler das Projekt nützlich finden, seinen Fortschritt verfolgen und es wahrscheinlich übernehmen werden. Um den Wert eines Projekts einzuschätzen, helfen Sterne dabei, die Traktion verschiedener Alternativen zu vergleichen und Einblicke in das Wachstum des Ökosystems zu gewinnen.

Ergebnisse im Detail

1 - Zu vermeidende Lösungen

Im Solid-Ökosystem gibt es keine eindeutig zu vermeidenden Lösungen.

2 - Akzeptable Lösungen

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

solid-i18next ist wahrscheinlich die beliebteste Option, da sie eine der ersten war, die die i18n-Anforderungen von JavaScript-Apps erfüllte. Sie verfügt außerdem über ein breites Set an Community-Plugins für spezifische Probleme.

Das Paket ist schwer (~14,6 KB, was etwa das 4,7-fache von solid-intlayer ist).

Trotzdem teilt es die gleichen großen Nachteile wie Stacks, die auf t('a.b.c') aufbauen: Optimierungen sind möglich, aber sehr zeitaufwendig, und große Projekte riskieren schlechte Praktiken (Namespaces + dynamisches Laden + Typen).

(@solid-primitives/i18n) (@solid-primitives/[email protected]):

Solid Primitive ist extrem leicht und effizient. Ich empfehle diese Lösung für leichte Projekte, aber es kann schnell an Funktionen für professionelle Lösungen fehlen, einschließlich Cookie-Management, Proxy-Redirection, Formatierer usw. Es fehlen auch Lazy-Loading und Scoping-Namespaces für die Optimierung der Seitengröße.

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

Paraglide bietet einen innovativen, gut durchdachten Ansatz. Dennoch funktionierte in diesem Benchmark das von der Firma beworbene Tree-Shaking für meine Implementierung nicht. Der Workflow und die DX sind ebenfalls komplexer als bei anderen Optionen. Persönlich gefällt mir nicht, dass JS-Dateien vor jedem Push neu generiert werden müssen, was ein ständiges Risiko für Merge-Konflikte bei PRs darstellt. Schließlich verwendet Paraglide im Vergleich zu anderen Lösungen keinen Store (z. B. Solid Signal), um das aktuelle Gebietsschema zum Rendern des Inhalts abzurufen. Für jeden geparsten Knoten wird das Gebietsschema aus dem localStorage / Cookie usw. angefordert. Dies führt zur Ausführung unnötiger Logik, die sich auf die Reaktivität der Komponenten auswirkt.

3 - Empfehlungen

(Intlayer) ([email protected]):

Ich werde solid-intlayer aus Gründen der Objektivität nicht persönlich beurteilen, da es meine eigene Lösung ist.

Persönliche Anmerkung

Diese Anmerkung ist persönlich und beeinflusst die Benchmark-Ergebnisse nicht. Dennoch sieht man in der i18n-Welt oft einen Konsens um ein Muster wie const t = useTranslation('xx') + <>{t('xx.xx')}</> für übersetzte Inhalte.

In Solid-Apps ist das Injizieren einer Funktion als JSX.Element meiner Meinung nach ein Anti-Pattern. Es fügt außerdem vermeidbare Komplexität und JavaScript-Ausführungs-Overhead hinzu (auch wenn dieser kaum merklich ist).