Skip to content

Comparison

Choose the i18n model you can keep.

For React and Solid teams that want source strings, repository-owned PO catalogs and one runtime model across supported hosts, Palamedes is the more durable default. That is a recommendation, not a claim that every alternative loses: each page states when another tool is the better fit, links the workflow outcome to proof, and keeps measured results separate from dated research.

01 — Comparison ledger

What we measured, what we researched, and where we made no claim.

8 libraries, 8 decisions. Start with the recommendation that fits your current architecture, then use this ledger to verify the evidence boundary. An empty measurement is an explicit boundary, not a footnote.

Comparison ledger, separating direct workflow measurements from dated research.
ComparisonMeasuredResearchedDetail

Palamedes vs Lingui

The closest relative — and the checked benchmark says 30× faster on the same workflow.

30.32× faster on realistic extract + catalog update¹

Scope: Extract + update, realistic corpus

Project and package research checked July 2026.

Observations, not a performance claim.

Read decision →

Palamedes vs fbtee

The modern FBT continuation — explicit grammar primitives and Expo support against standard PO/ICU catalogs and one native workflow.

100.12× faster on the checked same-inventory workflow¹

Scope: Collect + catalog update, realistic corpus

Project and package research checked August 2026.

Observations, not a performance claim.

Read decision →

Palamedes vs i18next

A key-first plugin architecture. One question splits it: do keys identify your messages, or does the text?

80.19× faster on realistic extract + catalog update¹

Scope: Extract + update, realistic corpus

Project and package research checked July 2026.

Observations, not a performance claim.

Read decision →

Palamedes vs next-intl

Next-native depth including routing, against one shared model across supported hosts.

Not measured — no claim implied.

Project and package research checked July 2026.

Observations, not a performance claim.

Read decision →

Palamedes vs React Intl

The ICU standard-bearer. Same rigor here, minus the Context tree that blocks server components.

5.85× faster on realistic extraction-only¹

Scope: Extract + update, realistic corpus

Project and package research checked July 2026.

Observations, not a performance claim.

Read decision →

Palamedes vs Paraglide (inlang)

Zero runtime and smaller bundles, against source-string authoring and standard .po catalogs.

Not measured — no claim implied.

Project and package research checked August 2026.

Observations, not a performance claim.

Read decision →

Palamedes vs Tolgee JS SDK

An MIT client runtime with broad framework bindings. The split is explicit keys versus extracted source strings.

Not measured — no claim implied.

Project and package research checked August 2026.

Observations, not a performance claim.

Read decision →

Palamedes vs Intlayer

The other anti-namespace project. It declares dictionaries; we read the sentence you wrote.

Not measured — no claim implied.

Project and package research checked July 2026.

Observations, not a performance claim.

Read decision →

02 — Not for you

When the honest answer is 'use something else'.

Every tool has edges, and pretending otherwise wastes your afternoon. In these four situations another library is simply the better call — you should not have to read four sections and a benchmark to find that out.

You build with Vue, Angular, or Svelte

Palamedes ships React and Solid packages only. Lingui covers Vue, i18next covers nearly everything, and vue-i18n is the idiomatic choice inside the Vue ecosystem.

You ship React Native

There is no React Native adapter here. fbtee has an explicit Expo path, while Lingui and i18next also support React Native today.

Kilobytes are your hard constraint

Paraglide's zero-runtime compilation beats a runtime layer on bundle size by construction. If that is the number you are judged on, start there.

You want the i18n library to own routing

next-intl treats localized pathnames and domain routing as core product. Palamedes leaves URLs to your router on purpose.

03 — ICU semantics

The durable claim is about the pipeline we control.

ICU support varies across libraries, TMS products, file formats and project settings, and any table claiming otherwise ages badly. Palamedes makes a bounded, executable claim instead: nested ICU selectors stay intact from source through transformation, PO catalogs, compilation and runtime rendering.

What we prove

One checked fixture exercises nested select and plural branches across extraction, transformation, catalog update, compilation, and six executions of the transformed runtime function. You can re-run it yourself.

What we only snapshot

Statements about other tools on these pages are dated observations from their public documentation and repositories — not permanent claims about their internals or where they are heading.

Re-run the proof and inspect the sources →

04 — The honest bit

Every tool on these pages is good software, built by people who thought hard about the problem — and every one of them was designed against a JavaScript toolchain that has since been rebuilt underneath them. We started on the other side of that line. If our tradeoffs do not match your team, all 26 of them are written down, so you can find that out today rather than in month four.

Start with the comparison that matches the risk you need to remove.