O dashboard de análise do seu cliente congela por 340 milissegundos toda vez que um usuário alterna o intervalo de datas em um gráfico com 3.000 pontos de dados. O reconciliador do React está processando nós da VDOM, os hooks estão disparando em cascata, e seu bundle apenas ultrapassou 180 kB gzipped. No trimestre passado reconstruímos este dashboard de produção exato—autenticação, atualizações WebSocket em tempo real, formulários complexos multi-etapas, módulo de gráficos—em SolidJS e React, instrumentamos cada renderização, registramos cada byte do bundle, e executamos os mesmos fluxos de usuário em ambas as versões. O gap de performance foi mais amplo do que esperávamos, mas não onde você pensaria.

Os resultados nos surpreenderam. Não porque um framework "venceu"—mas porque os trade-offs foram muito mais nuançados do que o discurso do Twitter sugere. Algumas coisas eram esperadas. Outras coisas nos pegaram completamente desprevenido. Isto é o que realmente aprendemos.

Índice

Construímos o Mesmo App em SolidJS e React: Signals vs Hooks

O App Que Construímos

A aplicação é um dashboard de análise em tempo real para um cliente de e-commerce. Aqui está o que inclui:

  • Fluxo de autenticação com tokens JWT e lógica de refresh
  • Dashboard com 6 painéis de widget, cada um puxando dados de diferentes endpoints de API
  • Feed de pedidos em tempo real usando conexões WebSocket
  • Gráficos interativos renderizando 5.000+ pontos de dados (usando uma biblioteca de gráficos)
  • Formulários de filtro complexos com dropdowns dependentes e seletores de intervalo de datas
  • Painel de configurações de admin com gerenciamento de estado aninhado
  • Layout responsivo com navegação de sidebar

Ambas as versões conectam à mesma API de backend. Ambas usam TypeScript. Ambas usam Vite como ferramenta de build. Mantemos dependências de terceiros o mais similares possível—mesma biblioteca de gráficos (Chart.js), mesmo cliente HTTP (ky), mesmo wrapper WebSocket.

A versão React usa React 19 com hooks. A versão SolidJS usa Solid 1.9. Não usamos nenhum meta-framework (sem Next.js, sem SolidStart) porque queríamos isolar as diferenças do framework sem roteamento e SSR confundindo a comparação.

Signals vs Hooks: Uma Mudança de Modelo Mental

Este é o grande. E honestamente, levou cerca de uma semana para nosso time parar de escrever código em estilo React em SolidJS.

Como React Hooks Funcionam

Você sabe disso, mas vale a pena declarar explicitamente para a comparação. O modelo do React é: quando o estado muda, a função do componente re-executa. A função inteira. Cada useState, cada useMemo, cada useCallback—são todos mecanismos para trabalhar ao redor do fato de que a função inteira re-executa.

// React: Esta função inteira re-executa em cada mudança de estado
function OrderFeed() {
  const [orders, setOrders] = useState([]);
  const [filter, setFilter] = useState('all');
  
  // Isto recalcula a cada renderização a menos que memoizemos
  const filteredOrders = useMemo(() => 
    orders.filter(o => filter === 'all' || o.status === filter),
    [orders, filter]
  );

  // Este ref é recriado conceitualmente a cada renderização
  const handleNewOrder = useCallback((order) => {
    setOrders(prev => [order, ...prev]);
  }, []);

  useEffect(() => {
    const ws = connectWebSocket(handleNewOrder);
    return () => ws.close();
  }, [handleNewOrder]);

  return <OrderList orders={filteredOrders} />;
}

Como Solid Signals Funcionam

O modelo do Solid é fundamentalmente diferente. A função do componente executa uma vez. Depois disso, apenas as expressões específicas que leem um signal re-executam quando esse signal muda. Não há VDOM. Não há reconciliação. O gráfico reativo rastreia exatamente quais nós do DOM dependem de quais signals.

// Solid: Esta função executa UMA VEZ
function OrderFeed() {
  const [orders, setOrders] = createSignal([]);
  const [filter, setFilter] = createSignal('all');
  
  // Isto é rastreado automaticamente—nenhum array de dependência necessário
  const filteredOrders = createMemo(() => 
    orders().filter(o => filter() === 'all' || o.status === filter())
  );

  // Nenhum useCallback necessário—este closure é estável
  const handleNewOrder = (order) => {
    setOrders(prev => [order, ...prev]);
  };

  // onMount em vez de useEffect com deps vazias
  onMount(() => {
    const ws = connectWebSocket(handleNewOrder);
    onCleanup(() => ws.close());
  });

  return <OrderList orders={filteredOrders()} />;
}

O Que Isto Significa na Prática

A versão Solid não tem arrays de dependência. Nenhum useCallback. Nenhum useMemo para estado derivado (embora createMemo exista para computações caras—a diferença é que é opt-in para performance, não necessário para correção).

Aqui está o que realmente nos mordeu durante o desenvolvimento:

  1. Desestruturação de props mata reatividade em Solid. Tínhamos um dev junior desestruturar props em um componente Solid e gastamos 45 minutos debugando por que atualizações não estavam se propagando. Em React, desestruturação é ok porque a função inteira re-executa. Em Solid, você precisa acessar props.value dentro do JSX ou de um escopo rastreado.

  2. Early returns são complicados em Solid. Você não pode fazer if (!data()) return <Loading /> no topo de um componente Solid do jeito que faria em React. A função do componente executa apenas uma vez, então esse condicional nunca seria re-avaliado. Você precisa usar <Show when={data()}> em vez disso.

  3. Sem bugs de closure obsoleto. Esta foi a grande vitória. Em nossa versão React, tínhamos três bugs de closure obsoleto separados na primeira semana relacionados a manipuladores WebSocket capturando estado antigo. A versão Solid teve zero, porque signals são sempre lidos no momento do acesso, não capturados em um closure.

Comparação de Tamanho de Bundle

Medimos ambos os builds de produção com a mesma configuração do Vite, compressão gzip, e estratégia de code splitting.

Métrica React 19 SolidJS 1.9 Diferença
Runtime do framework 44.2 KB (gzip) 7.1 KB (gzip) -84%
Bundle inicial total 127.8 KB 89.3 KB -30%
App total (todos os chunks) 312.4 KB 274.1 KB -12%
Primeiro chunk (caminho crítico) 68.4 KB 41.2 KB -40%
Número de chunks 14 14 Igual

O runtime do Solid é dramaticamente menor. Isso não é notícia—Ryan Carniato falou extensivamente sobre isto. Mas o que nos surpreendeu foi que a diferença de tamanho total do app se estreitou significativamente uma vez que você adiciona código de aplicação real, bibliotecas de terceiros, e assets.

O runtime do framework importa mais para carga inicial. E com 7.1 KB gzipped, Solid basicamente desaparece no ruído. O 44 KB do React é notável, especialmente em conexões móveis.

Tree Shaking

Solid faz tree-shaking melhor que React. Primitivas Solid não utilizadas são eliminadas inteiramente. Com React, o reconciliador e a arquitetura de fiber são enviados independentemente de você usar todos seus recursos ou não. Confirmamos isto construindo uma página mínima em ambos—o piso do Solid é mais baixo.

Construímos o Mesmo App em SolidJS e React: Signals vs Hooks - arquitetura

Benchmarks de Performance de Renderização

Executamos benchmarks estruturados usando Chrome DevTools performance profiles, Lighthouse, e instrumentação de timing customizado. Todos os testes em um MacBook Pro M2 com CPU throttling definido para 4x slowdown para simular dispositivos de faixa média.

Renderização de Gráfico (5.000 pontos de dados)

Métrica React 19 SolidJS 1.9
Renderização inicial 142ms 89ms
Re-renderização na mudança de filtro 67ms 23ms
Memória durante renderização 18.4 MB 11.2 MB
Nós do DOM criados 5.847 5.812

Solid foi consistentemente mais rápido em re-renderizações porque não faz diff em uma árvore de DOM virtual. Quando um signal de filtro muda, apenas as expressões que leem esse signal atualizam. As melhorias do compilador do React 19 ajudaram—o mesmo teste em React 18 era 95ms para re-renderizações—mas Solid ainda tinha uma vantagem clara.

Feed de Pedidos em Tempo Real (100 atualizações/segundo)

Isto é onde as coisas ficaram realmente interessantes. Empurramos 100 mensagens WebSocket por segundo no feed de pedidos.

Métrica React 19 SolidJS 1.9
Quedas de frame (por 10s) 12 2
Tempo médio de paint 8.3ms 3.1ms
Tempo máximo de paint 34ms 11ms
Uso de CPU (média) 24% 9%

Solid absolutamente esmagou este benchmark. Atualizações de alta frequência é onde a reatividade fine-grained paga os maiores dividendos. React estava fazendo batching de atualizações (o que é bom), mas ainda fazendo diff em mais DOM que o necessário em cada batch.

Devemos notar: useTransition do React 19 e batching automático tornaram isto muito melhor do que React 18 teria sido. E para a maioria dos apps do mundo real, você não está empurrando 100 atualizações por segundo. Em 10 atualizações/segundo, ambos os frameworks eram suaves.

Formulário Complexo com 40 Campos

Métrica React 19 SolidJS 1.9
Lag de entrada do keystroke 2-4ms <1ms
Renderização de submissão de formulário 28ms 12ms
Re-renderizações de componente por keystroke 3-8 1

Em React, digitar em um campo causaria componentes pais a re-renderizar a menos que memoizássemos cuidadosamente tudo. Em Solid, digitar em um campo literalmente só atualiza aquele nó de texto do DOM do campo. Nada mais re-executa.

Experiência do Desenvolvedor e Ecossistema

Performance não é tudo. Você tem que realmente construir a coisa, debugá-la, contratar para ela, e mantê-la.

Tamanho do Ecossistema (a partir de início de 2026)

Fator React SolidJS
Downloads semanais no npm ~28M ~85K
GitHub stars 233K+ 33K+
Perguntas no Stack Overflow 470K+ ~2K
Bibliotecas de componentes UI 50+ opções maduras 5-8 opções
Postagens de emprego (LinkedIn EUA) ~45.000 ~200
Meta-framework Next.js (maduro) SolidStart (beta)

Este é o elefante na sala. O ecossistema do React é ordens de magnitude maior. Quando precisávamos de um date range picker para Solid, tínhamos que fazer port de um do React ou escrever o nosso. Em React, tínhamos 15 opções para escolher.

Usamos Kobalte para primitivas de UI acessíveis em Solid, e é genuinamente bom. Mas não é Radix UI em termos de cobertura de componentes.

Debugging

React DevTools é maduro, bem-mantido, e algo que todo dev frontend conhece. Solid tem sua própria extensão DevTools, e é decente—você pode inspecionar o gráfico de signals, o que é realmente mais útil para rastrear bugs de reatividade do que a visualização de árvore de componentes do React. Mas é menos polido.

Suporte TypeScript

Ambos são excelentes. O suporte TypeScript do Solid é na verdade ligeiramente melhor para JSX porque o compilador manipula mais no tempo de build. Tínhamos menos ginástica de tipo no codebase do Solid.

Trade-offs de Produção Que Realmente Importam

Depois de construir ambas as versões e implementar a versão Solid em staging (o cliente finalmente escolheu React para produção—mais sobre isso abaixo), aqui estão os trade-offs que realmente importaram:

Contratação

Nosso cliente tem um time de 8 desenvolvedores frontend. Todos conhecem React. Nenhum havia usado Solid. Estimativa de tempo de treinamento: 2-3 semanas para proficiência, 2-3 meses para maestria. Esse é um custo real. Este é o único fator maior na maioria das decisões de produção, e é por que normalmente recomendamos React ou frameworks como Next.js para times que precisam contratar frequentemente.

Compatibilidade de Biblioteca de Terceiros

Tivemos que escrever wrappers customizados para três bibliotecas que tinham integrações específicas do React. Isto adicionou aproximadamente 20 horas de tempo de desenvolvimento. Em um projeto React, essas horas não existem.

Server-Side Rendering

SolidStart é promissor mas ainda estava em beta durante nosso projeto. Next.js é battle-tested. Para projetos onde precisamos de SSR em nível de produção com todos os acessórios, ainda estamos alcançando Next.js development ou Astro dependendo do modelo de conteúdo.

Performance Onde Importa

Aqui está a verdade honesta: para este dashboard em particular, ambos os frameworks performaram bem o suficiente para produção. A versão Solid era mensuravelmente mais rápida, mas a versão React nunca foi lenta. Usuários não notariam a diferença na maioria das interações.

A exceção foi o feed em tempo real em altas frequências de atualização. Se seu app tem um caso de uso como aquele, a vantagem de performance do Solid é significativa, não apenas bravata de benchmark.

Quando Escolher SolidJS em vez de React

Depois dessa experiência, aqui está nosso framework honesto para a decisão:

Escolha SolidJS quando:

  • Seu app tem atualizações reativas de alta frequência (dashboards, plataformas de trading, colaboração em tempo real)
  • Tamanho de bundle é crítico (widgets embedded, micro-frontends, mobile-first)
  • Seu time é pequeno e disposto a investir em aprender um novo paradigma
  • Você quer reatividade fine-grained sem lutar contra o framework
  • Você está construindo algo novo e não precisa de um ecossistema massivo de biblioteca de componentes

Escolha React quando:

  • Seu time já conhece React (isto sozinho é normalmente decisivo)
  • Você precisa de um meta-framework maduro (Next.js, Remix)
  • Disponibilidade de biblioteca de terceiros é importante
  • Você está contratando e precisa de um grande pool de talentos
  • Os requisitos de performance do seu app são típicos (não extremos)

Para nossos projetos de headless CMS development, React ainda domina porque integrações de CMS (Sanity, Contentful, Storyblok) têm SDKs React de primeira classe. Suporte Solid existe mas é frequentemente mantido pela comunidade.

Comparação de Código: Padrões Reais

Vamos olhar para alguns padrões reais do projeto lado a lado.

Fetching de Dados com Estados de Carregamento

React:

function Dashboard() {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetchDashboardData()
      .then(setData)
      .catch(setError)
      .finally(() => setLoading(false));
  }, []);

  if (loading) return <Skeleton />;
  if (error) return <ErrorBanner error={error} />;
  return <DashboardGrid data={data} />;
}

SolidJS:

function Dashboard() {
  const [data] = createResource(fetchDashboardData);

  return (
    <Suspense fallback={<Skeleton />}>
      <ErrorBoundary fallback={(err) => <ErrorBanner error={err} />}>
        <DashboardGrid data={data()} />
      </ErrorBoundary>
    </Suspense>
  );
}

O createResource do Solid com Suspense é genuinamente elegante. React tem Suspense também (e ficou melhor em React 19), mas a versão do Solid se sentiu mais natural para trabalhar. Menos boilerplate, menos variáveis de estado para gerenciar.

Renderização Condicional

React:

{user ? (
  <Profile user={user} />
) : (
  <LoginPrompt />
)}

SolidJS:

<Show when={user()} fallback={<LoginPrompt />}>
  {(u) => <Profile user={u()} />}
</Show>

O <Show> do Solid existe porque ternários não funcionam da mesma forma quando a função do componente executa apenas uma vez. Levou um tempo para se acostumar, mas o padrão de callback lhe dá uma referência estreitada, não-nula, o que é bom para TypeScript.

Renderização de Lista

React:

{orders.map(order => (
  <OrderRow key={order.id} order={order} />
))}

SolidJS:

<For each={orders()}>
  {(order) => <OrderRow order={order} />}
</For>

O <For> do Solid não precisa de keys porque rastreia itens de array por referência. Quando um item se move no array, Solid move o nó real do DOM. React desmontaria e remontaria. É por isto que a performance de lista do Solid é tão boa.

FAQ

SolidJS está pronto para produção em 2026?

Sim. Solid 1.x tem sido estável por mais de dois anos. Empresas como Cloudflare e Samsung a usaram em produção. A biblioteca central é madura e bem-testada. O ecossistema ao redor dela (SolidStart, bibliotecas de componentes) é menor do que o do React mas crescendo constantemente. A questão não é se Solid está pronta—é se seu time e requisitos do projeto se alinham com o tamanho de seu ecossistema.

Posso migrar do React para SolidJS incrementalmente?

Não facilmente. Apesar da sintaxe JSX similar, os modelos de runtime são fundamentalmente diferentes. Você não pode incorporar componentes Solid dentro de um app React (ou vice versa) sem limites de iframe ou web component. Uma migração seria essencialmente uma reescrita. Se você está considerando, comece com um recurso isolado novo ou micro-frontend em vez de tentar converter código React existente.

SolidJS suporta server-side rendering?

Sim. SolidStart fornece SSR, streaming, e server functions. É funcional e melhorando rapidamente, mas a partir de início de 2026, ainda é menos maduro do que Next.js ou Remix. Para projetos pesados em SSR, ainda recomendaríamos avaliar Next.js ou Astro dependendo de suas necessidades de conteúdo.

Como o compilador do React 19 compara com a abordagem do Solid?

O compilador do React 19 (anteriormente React Forget) auto-memoiza componentes para reduzir re-renderizações desnecessárias. É uma melhoria significativa. Mas ainda está trabalhando dentro do modelo do React de re-executar funções de componente e fazer diff de uma DOM virtual. Solid pula ambas essas etapas inteiramente. O compilador torna React mais rápido, mas não muda a arquitetura fundamental. Em nossos benchmarks, React 19 com o compilador era cerca de 30% mais rápido que React 18, mas ainda mais lento que Solid em cenários heavy de atualização.

E quanto ao Preact Signals como um meio termo?

Preact Signals (e o adaptador @preact/signals-react) trazem reatividade tipo signal para o ecossistema React. É uma abordagem interessante, mas está lutando contra o modelo central do React em vez de trabalhar com ele. Testamos brevemente e encontramos edge cases com Suspense e recursos concorrentes. Se você quer signals, Solid lhe dá a experiência completa sem o impedance mismatch.

SolidJS é mais difícil de aprender que React?

Se você já conhece React, a API do Solid parecerá familiar—JSX similar, padrões similares. A parte difícil é desaprender o modelo mental do React. Você alcançará padrões useEffect que não existem. Você desestruturará props e quebrará reatividade. Você tentará early returns e se perguntará por que não funcionam. Separe cerca de 1-2 semanas para um dev React experiente se tornar produtivo em Solid, e mais um ou dois meses para parar de escrever Solid com sabor React.

Qual framework tem melhor suporte TypeScript?

Ambos têm excelente suporte TypeScript. Solid tem uma ligeira vantagem porque seu compilador pode fornecer tipos mais estreitos em certos padrões (como o callback em <Show>), e você não precisa do mesmo volume de parâmetros de tipo genéricos que alguns hooks React complexos às vezes requerem. Mas honestamente, ambos são ótimos. Isto não deveria ser um fator decisivo.

Devo usar SolidJS para meu próximo projeto?

Depende de suas limitações. Se você é um time pequeno construindo algo sensível à performance e disposto a investir em curva de aprendizado e trabalhar ao redor de um ecossistema menor, Solid é uma escolha genuinamente excelente. Se você precisa contratar desenvolvedores React, usar bibliotecas de componentes estabelecidas, ou precisa de um meta-framework battle-tested para produção, React é a aposta mais segura. Não há uma resposta universal—apenas a resposta correta para sua situação específica. Se você quer conversar sobre a decisão para seu projeto, entre em contato conosco e podemos ajudá-lo a avaliar os trade-offs.