Bibliotecas i18n para Solid - Relatório de Benchmark 2026

Esta página é um relatório de benchmark para soluções i18n no Solid.

Índice

Benchmark Interativo

Referência de resultados:

Ver dados completos do benchmark

Veja o repositório completo do benchmark aqui.

Introdução

As soluções de internacionalização estão entre as dependências mais pesadas em um app Solid. O principal risco é enviar conteúdo desnecessário: traduções para outras páginas e outros locais no bundle de uma única rota.

À medida que seu app cresce, esse problema pode rapidamente explodir o JavaScript enviado ao cliente e tornar a navegação lenta.

Na prática, para as implementações menos otimizadas, uma página internacionalizada pode acabar sendo várias vezes mais pesada do que a versão sem i18n.

O outro impacto é na experiência do desenvolvedor (DX): como você declara conteúdo, tipos, organização de namespaces, carregamento dinâmico e reatividade quando o local muda.

TL;DR

• Intlayer: Escolha recomendada para aplicações Solid profissionais que precisam de recursos avançados e otimização (v8.7.12).
• @solid-primitives/i18n: Excelente alternativa leve para projetos simples, embora careça de recursos avançados como lazy loading.
• solid-i18next: Opção padrão, mas pesada (~4.7× o Intlayer) com os mesmos pontos negativos do React i18next.
• Paraglide: Abordagem inovadora, mas DX complexa e problemas de tree-shaking em algumas configurações.

Teste seu app

Para identificar rapidamente problemas de vazamento de i18n, configurei um scanner gratuito disponível aqui.

O problema

Duas alavancas são essenciais para limitar o custo de um app multilíngue:

• Dividir o conteúdo por página / namespace para não carregar dicionários inteiros quando não for necessário.
• Carregar o local correto dinamicamente, apenas quando necessário.

Entendendo as limitações técnicas dessas abordagens:

Carregamento dinâmico

Sem carregamento dinâmico, a maioria das soluções mantém as mensagens na memória desde o primeiro render, o que adiciona um overhead significativo para apps com muitas rotas e locais.

Com carregamento dinâmico, você aceita uma troca: menos JS inicial, mas às vezes uma requisição extra ao trocar de idioma.

Divisão de conteúdo (Splitting)

Sintaxes construídas em torno de t('a.b.c') são muito convenientes, mas frequentemente incentivam a manutenção de grandes objetos JSON em tempo de execução. Esse modelo torna o tree-shaking difícil, a menos que a biblioteca ofereça uma estratégia real de divisão por página.

Metodologia

Para este benchmark, comparamos as seguintes bibliotecas:

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

O framework é Solid com um app multilíngue de 10 páginas e 10 idiomas.

Comparamos quatro estratégias de carregamento:

Resumo das estratégias

• Static: Simples; sem latência de rede após o carregamento inicial. Desvantagem: grande tamanho de bundle.
• Dynamic: Reduz o peso inicial (lazy-loading). Ideal quando você tem muitos locais.
• Scoped static: Mantém o código organizado (separação lógica) sem requisições de rede extras complexas.
• Scoped dynamic: Melhor abordagem para code splitting e desempenho. Minimiza a memória carregando apenas o que a view atual e o local ativo precisam.

Estrelas do GitHub

As estrelas do GitHub são um forte indicador da popularidade de um projeto, da confiança da comunidade e da relevância a longo prazo. Embora não sejam uma medida direta da qualidade técnica, elas refletem quantos desenvolvedores consideram o projeto útil, acompanham seu progresso e têm probabilidade de adotá-lo. Para estimar o valor de um projeto, as estrelas ajudam a comparar a tração entre as alternativas e fornecem insights sobre o crescimento do ecossistema.

Resultados em detalhes

1 - Soluções a evitar

Nenhuma solução clara a evitar no ecossistema Solid.

2 - Soluções aceitáveis

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

O solid-i18next é provavelmente a opção mais popular porque foi uma das primeiras a atender às necessidades de i18n de apps JavaScript. Também possui um amplo conjunto de plugins da comunidade para problemas específicos.

O pacote é pesado (~14.6kb, o que é cerca de 4.7× o solid-intlayer).

Ainda assim, compartilha as mesmas principais desvantagens das stacks construídas sobre o t('a.b.c'): otimizações são possíveis, mas consomem muito tempo, e grandes projetos correm o risco de más práticas (namespaces + carregamento dinâmico + tipos).

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

O Solid primitive é extremamente leve e eficiente. Recomendo essa solução para projetos leves, mas pode rapidamente carecer de recursos para soluções profissionais que incluam gerenciamento de cookies, redirecionamento de proxy, formatadores etc. Também carece de lazy loading e scoping de namespaces para otimização do tamanho da página.

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

O Paraglide oferece uma abordagem inovadora e bem pensada. Ainda assim, neste benchmark, o tree-shaking que a empresa anuncia não funcionou para minha implementação. O fluxo de trabalho e a DX também são mais complexos do que outras opções. Pessoalmente, não gosto de ter que regenerar arquivos JS antes de cada push, o que cria um risco constante de conflito de merge através de PRs. Finalmente, em comparação com outras soluções, o Paraglide não usa um store (ex: Solid signal) para recuperar o local atual para renderizar o conteúdo. Para cada nó analisado, ele solicitará o local do localStorage / cookie etc. Isso leva à execução de lógica desnecessária que impacta a reatividade do componente.

3 - Recomendações

(Intlayer) ([email protected]):

Eu não julgarei pessoalmente o solid-intlayer por uma questão de objetividade, já que é minha própria solução.

Nota pessoal

Esta nota é pessoal e não afeta os resultados do benchmark. Ainda assim, no mundo do i18n, você costuma ver consenso em torno de um padrão como const t = useTranslation('xx') + <>{t('xx.xx')}</> para o conteúdo traduzido.

Em apps Solid, injetar uma função como um JSX.Element é, na minha opinião, um antipadrão. Também adiciona complexidade evitável e overhead de execução de JavaScript (mesmo que seja quase imperceptível).