Paraglide JS - Zero Runtime I18n for React

Why Paraglide JS?

Paraglide JS represents a paradigm shift in web internationalization. Instead of shipping a large JSON file of keys and a runtime parser to the browser, Paraglide behaves like a compiler. It turns your translation files into pure JavaScript functions.

Zero Runtime Overhead: There is no interpolation engine running in the browser. A translation like Hello {name} is compiled into a simple template literal function (args) => `Hello ${args.name}`.
Unmatched Type Safety: Because messages are functions, TypeScript naturally validates the arguments. If you miss a parameter or mistype a variable, your build will fail.
Tree-Shaking: You only import the messages you use. If a translation key is never used in your code, it is never included in your final bundle, significantly reducing bundle size for large apps.
Framework Agnostic: While it has a React adapter, the core output is standard JavaScript, making it usable in Svelte, Vue, Solid, or vanilla JS backends seamlessly.
Inlang Integration: It is built on the Inlang ecosystem, meaning it works natively with their Visual Studio Code extension for inline editing and linting of translations.

Code Snippet

Using Paraglide JS in a React component. Notice that messages are imported functions, not string keys.

import * as m from "./paraglide/messages"
import { getLocale } from "./paraglide/runtime"

export function WelcomeBanner({ userName, unreadCount }) {
  return (
    <div className="banner">
      {/* 1. Standard Message */}
      <h1>{m.welcome_title()}</h1>
      
      {/* 2. Message with arguments (Type-Checked!) */}
      <p>{m.greeting({ name: userName })}</p>
      
      {/* 3. Complex logic is compiled away */}
      <span className="badge">
        {m.unread_messages({ count: unreadCount })}
      </span>

      <p>Current Language: {getLocale()}</p>
    </div>
  )
}

In this example, m.greeting is not a lookup string "greeting". It is a real function. If you try to call m.greeting({ nme: 'Alex' }) (typo), TypeScript will error immediately.

Pros and Cons

No library is perfect; understanding the trade-offs is key to selecting the right tool.

Pros

Performance: It is arguably the fastest i18n solution available because it eliminates the parsing step entirely at runtime.
Developer Experience: The "Go to Definition" feature in your IDE actually works, taking you straight to the translation logic. Autocomplete for message arguments is flawless.
Bundle Size: For large applications with thousands of keys, only the keys used on the current page (if code-split) or in the app are bundled.

Cons

Build Step: It relies entirely on its compiler. You must run the Paraglide compiler (paraglide-js compile) whenever you change translation files to see updates in code.
Newer Ecosystem: As a newer entrant, it has fewer community plugins and third-party integrations compared to giants like i18next.
Dynamic Keys: You cannot easily "construct" keys dynamically (e.g., m['error_' + code]) because the compiler needs to statically analyze usage for tree-shaking.

Comparison with Other I18n Libraries

The table below outlines the positioning differences between Paraglide JS and other popular I18n libraries to help you make an informed decision:

Library	Design Philosophy	Best For	Pain Points
Paraglide JS	Compile-to-JS Treats translations as code, not data. Prioritizes types and performance.	Modern Web Apps Projects using TypeScript that care about bundle size and DX.	Dynamic Data Harder to use if your translation keys come from an API database.
react-i18next	Runtime Power Loads and parses JSON at runtime. Highly dynamic.	Legacy / Enterprise Massive apps requiring dynamic loading of remote translation files.	Bundle Size The runtime parser and full translation JSONs can be heavy.
react-intl	Standards First Uses native browser `Intl` APIs and ICU syntax.	Formatting Heavy Apps needing precise date/number/currency formatting compliance.	Verbosity High boilerplate for simple text strings compared to direct imports.

Verdict: When to Adopt

Choose Paraglide JS if you are building a modern, TypeScript-first application and want the absolute best Developer Experience regarding type safety and autocomplete. It is the ideal choice for teams who want to catch missing translation arguments at compile time rather than finding "undefined" in production. If you need to load translations dynamically from a CMS API at runtime, a traditional library like i18next might be more suitable.

TL;DR