Le dashboard d'analyse de votre client se fige pendant 340 millisecondes chaque fois qu'un utilisateur bascule la plage de dates sur un graphique contenant 3 000 points de données. Le reconciler de React traite les nœuds VDOM, les hooks s'exécutent en cascade, et votre bundle vient de dépasser 180 kB compressé. Le trimestre dernier, nous avons reconstruit ce dashboard exactement identique en production—authentification, mises à jour WebSocket en temps réel, formulaires multi-étapes complexes, module de graphique—dans SolidJS et React, instrumenté chaque rendu, journalisé chaque octet du bundle, et exécuté les mêmes flux utilisateur dans les deux versions. L'écart de performance était plus large que prévu, mais pas où vous l'auriez pensé.

Les résultats nous ont surpris. Non pas parce qu'un framework « a gagné »—mais parce que les compromis étaient bien plus nuancés que le discours sur Twitter le suggère. Certaines choses nous l'attendions. D'autres nous ont complètement surpris. Voici ce que nous avons réellement appris.

Table des matières

We Built the Same App in SolidJS and React: Signals vs Hooks

L'application que nous avons construite

L'application est un dashboard d'analyse en temps réel pour un client e-commerce. Voici ce qu'elle inclut :

  • Flux d'authentification avec tokens JWT et logique de rafraîchissement
  • Dashboard avec 6 panneaux de widgets, chacun récupérant les données depuis différents points d'accès API
  • Flux de commandes en temps réel utilisant des connexions WebSocket
  • Graphiques interactifs rendant 5 000+ points de données (utilisant une bibliothèque de graphiques)
  • Formulaires de filtre complexes avec dropdowns dépendants et sélecteurs de plage de dates
  • Panneau de paramètres d'administration avec gestion d'état imbriquée
  • Mise en page réactive avec navigation par sidebar

Les deux versions se connectent au même API backend. Les deux utilisent TypeScript. Les deux utilisent Vite comme outil de build. Nous avons maintenu les dépendances tierces aussi similaires que possible—même bibliothèque de graphiques (Chart.js), même client HTTP (ky), même wrapper WebSocket.

La version React utilise React 19 avec hooks. La version SolidJS utilise Solid 1.9. Nous n'avons utilisé aucun meta-frameworks (pas Next.js, pas SolidStart) parce que nous voulions isoler les différences entre les frameworks sans que le routage et SSR ne brouillent la comparaison.

Signals vs Hooks : un changement de modèle mental

C'est le gros morceau. Et honnêtement, il a fallu environ une semaine à notre équipe pour arrêter d'écrire du code en forme React en SolidJS.

Comment fonctionnent les Hooks React

Vous le savez, mais c'est utile de le préciser explicitement pour la comparaison. Le modèle de React est : quand l'état change, la fonction du composant se réexécute. La fonction entière. Chaque useState, chaque useMemo, chaque useCallback—ils sont tous des mécanismes pour contourner le fait que la fonction entière se réexécute.

// React : Cette fonction entière se réexécute à chaque changement d'état
function OrderFeed() {
  const [orders, setOrders] = useState([]);
  const [filter, setFilter] = useState('all');
  
  // Ceci se recalcule à chaque rendu sauf si nous le mémorisons
  const filteredOrders = useMemo(() => 
    orders.filter(o => filter === 'all' || o.status === filter),
    [orders, filter]
  );

  // Cette ref est conceptuellement recréée à chaque rendu
  const handleNewOrder = useCallback((order) => {
    setOrders(prev => [order, ...prev]);
  }, []);

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

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

Comment fonctionnent les Signals Solid

Le modèle de Solid est fondamentalement différent. La fonction du composant s'exécute une seule fois. Après cela, seules les expressions spécifiques qui lisent un signal se réexécutent quand ce signal change. Il n'y a pas de VDOM. Il n'y a pas de réconciliation. Le graphe réactif suit exactement quels nœuds DOM dépendent de quels signals.

// Solid : Cette fonction s'exécute UNE SEULE FOIS
function OrderFeed() {
  const [orders, setOrders] = createSignal([]);
  const [filter, setFilter] = createSignal('all');
  
  // Ceci est automatiquement suivi—aucun tableau de dépendances nécessaire
  const filteredOrders = createMemo(() => 
    orders().filter(o => filter() === 'all' || o.status === filter())
  );

  // Pas besoin de useCallback—cette closure est stable
  const handleNewOrder = (order) => {
    setOrders(prev => [order, ...prev]);
  };

  // onMount au lieu de useEffect avec des dépendances vides
  onMount(() => {
    const ws = connectWebSocket(handleNewOrder);
    onCleanup(() => ws.close());
  });

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

Ce que cela signifie en pratique

La version Solid n'a pas de tableaux de dépendances. Pas de useCallback. Pas de useMemo pour l'état dérivé (bien que createMemo existe pour les calculs coûteux—la différence est que c'est optionnel pour la performance, pas requis pour la correction).

Voici ce qui nous a vraiment causé des problèmes pendant le développement :

  1. Déstructurer les props tue la réactivité en Solid. Un développeur junior a déstructuré les props dans un composant Solid et nous avons passé 45 minutes à déboguer pourquoi les mises à jour n'étaient pas propagées. En React, la déstructuration est fine parce que la fonction entière se réexécute. En Solid, vous devez accéder à props.value à l'intérieur du JSX ou d'une portée suiveie.

  2. Les retours anticipés sont délicats en Solid. Vous ne pouvez pas faire if (!data()) return <Loading /> au début d'un composant Solid de la même façon qu'en React. La fonction du composant ne s'exécute qu'une seule fois, donc cette condition ne serait jamais réévaluée. Vous devez utiliser <Show when={data()}> à la place.

  3. Pas de bugs de closure éventée. C'était la grosse victoire. Dans notre version React, nous avions trois bugs de closure éventée distincts la première semaine liés aux gestionnaires WebSocket capturant l'ancien état. La version Solid en avait zéro, parce que les signals sont toujours lus au moment de l'accès, non capturés dans une closure.

Comparaison de la taille du bundle

Nous avons mesuré les deux builds de production avec la même configuration Vite, compression gzip, et stratégie de code splitting.

Métrique React 19 SolidJS 1.9 Différence
Runtime du framework 44,2 KB (gzip) 7,1 KB (gzip) -84%
Bundle initial total 127,8 KB 89,3 KB -30%
Application totale (tous les chunks) 312,4 KB 274,1 KB -12%
Premier chunk (chemin critique) 68,4 KB 41,2 KB -40%
Nombre de chunks 14 14 Identique

Le runtime de Solid est dramatiquement plus petit. Ce n'est pas une nouveauté—Ryan Carniato en a parlé extensivement. Mais ce qui nous a surpris, c'est que la différence de taille totale d'application s'est rétrécie significativement une fois que vous ajoutez du code applicatif réel, des bibliothèques tierces, et des assets.

Le runtime du framework importe le plus pour le chargement initial. Et à 7,1 KB gzipped, Solid disparaît essentiellement dans le bruit. Les 44 KB de React sont notables, surtout sur les connexions mobiles.

Tree Shaking

Solid tree-shake mieux que React. Les primitives Solid inutilisées sont complètement éliminées. Avec React, le reconciler et l'architecture fiber sont chargés que vous utilisiez toutes leurs fonctionnalités ou non. Nous avons confirmé cela en construisant une page minimale dans les deux—le plancher de Solid est plus bas.

We Built the Same App in SolidJS and React: Signals vs Hooks - architecture

Benchmarks de performance du rendu

Nous avons exécuté des benchmarks structurés utilisant les profils de performance Chrome DevTools, Lighthouse, et une instrumentation de timing personnalisée. Tous les tests sur un MacBook Pro M2 avec CPU throttling défini à 4x slowdown pour simuler des appareils de milieu de gamme.

Rendu de graphique (5 000 points de données)

Métrique React 19 SolidJS 1.9
Rendu initial 142ms 89ms
Re-rendu lors du changement de filtre 67ms 23ms
Mémoire pendant le rendu 18,4 MB 11,2 MB
Nœuds DOM créés 5 847 5 812

Solid était constamment plus rapide aux re-rendus parce qu'il ne difie pas un arbre VDOM. Quand un signal de filtre change, seules les expressions qui lisent ce signal se mettent à jour. Les améliorations du compilateur React 19 ont aidé—le même test sur React 18 était 95ms pour les re-rendus—mais Solid avait toujours un avantage clair.

Flux de commandes en temps réel (100 mises à jour/seconde)

C'est là que les choses se sont devenues vraiment intéressantes. Nous avons poussé 100 messages WebSocket par seconde dans le flux de commandes.

Métrique React 19 SolidJS 1.9
Chutes d'images (par 10s) 12 2
Temps de paint moyen 8,3ms 3,1ms
Temps de paint max 34ms 11ms
Utilisation CPU (moy) 24% 9%

Solid a absolument écrasé ce benchmark. Les mises à jour haute fréquence sont où la réactivité fine-grained paie les plus gros dividendes. React regroupait les mises à jour (ce qui est bon), mais différenciait toujours plus de DOM que nécessaire à chaque regroupement.

Nous devons noter : useTransition de React 19 et le regroupement automatique ont amélioré cela bien au-delà de ce que React 18 aurait été. Et pour la plupart des applications réelles, vous ne poussez pas 100 mises à jour par seconde. À 10 mises à jour/seconde, les deux frameworks étaient fluides.

Formulaire complexe avec 40 champs

Métrique React 19 SolidJS 1.9
Lag d'entrée des touches 2-4ms <1ms
Rendu de soumission de formulaire 28ms 12ms
Re-rendus de composant par frappe de touche 3-8 1

En React, taper dans un champ causerait le re-rendu des composants parents sauf si nous mémorisions soigneusement tout. En Solid, taper dans un champ met à jour littéralement uniquement le nœud texte DOM de ce champ. Rien d'autre ne se réexécute.

Expérience développeur et écosystème

La performance n'est pas tout. Vous devez réellement construire la chose, la déboguer, embaucher pour elle, et la maintenir.

Taille de l'écosystème (début 2026)

Facteur React SolidJS
Téléchargements npm hebdomadaires ~28M ~85K
Étoiles GitHub 233K+ 33K+
Questions Stack Overflow 470K+ ~2K
Bibliothèques de composants UI 50+ options matures 5-8 options
Offres d'emploi (LinkedIn US) ~45 000 ~200
Meta-framework Next.js (mature) SolidStart (bêta)

C'est l'éléphant dans la pièce. L'écosystème de React est des ordres de magnitude plus grand. Quand nous avons eu besoin d'un sélecteur de plage de dates pour Solid, nous avons dû soit porter un de React, soit écrire le nôtre. En React, nous avions 15 options parmi lesquelles choisir.

Nous avons utilisé Kobalte pour les primitives UI accessibles en Solid, et c'est véritablement bon. Mais ce n'est pas Radix UI en termes de couverture de composants.

Débogage

React DevTools est mature, bien maintenu, et quelque chose que chaque développeur frontend connaît. Solid a sa propre extension DevTools, et c'est décent—vous pouvez inspecter le graphe de signal, ce qui est en fait plus utile pour tracer les bugs de réactivité que la vue de l'arbre de composants de React. Mais c'est moins poli.

Support TypeScript

Les deux sont excellents. Le support TypeScript de Solid est légèrement meilleur pour JSX parce que le compilateur gère davantage au moment du build. Nous avons eu moins de contorsions de type dans la base de code Solid.

Compromis en production qui comptent vraiment

Après avoir construit les deux versions et déployé la version Solid en staging (le client a finalement choisi React pour la production—plus sur cela ci-dessous), voici les compromis qui ont réellement importé :

Embauche

Notre client a une équipe de 8 développeurs frontend. Tous connaissent React. Aucun n'avait utilisé Solid. Estimation du temps de formation : 2-3 semaines pour la compétence, 2-3 mois pour la maîtrise. C'est un coût réel. C'est le facteur unique le plus important dans la plupart des décisions de production, et c'est pourquoi nous recommandons généralement React ou des frameworks comme Next.js pour les équipes qui ont besoin d'embaucher fréquemment.

Compatibilité des bibliothèques tierces

Nous avons dû écrire des wrappers personnalisés pour trois bibliothèques qui avaient des intégrations spécifiques à React. Cela a ajouté environ 20 heures de temps de développement. Dans un projet React, ces heures n'existent pas.

Rendu côté serveur

SolidStart est prometteur mais était toujours en bêta pendant notre projet. Next.js est éprouvé. Pour les projets où nous avons besoin du SSR de qualité production avec tous les équipements, nous cherchons toujours développement Next.js ou Astro selon le modèle de contenu.

Performance où elle compte

Voici la vérité honnête : pour ce dashboard particulier, les deux frameworks ont performé assez bien pour la production. La version Solid était mesurément plus rapide, mais la version React n'a jamais été lente. Les utilisateurs ne remarqueraient pas la différence dans la plupart des interactions.

L'exception était le flux en temps réel à haute fréquence de mises à jour. Si votre application a un cas d'usage comme celui-ci, l'avantage de performance de Solid est significatif, pas juste de la fanfaronnade de benchmark.

Quand choisir SolidJS plutôt que React

Après cette expérience, voici notre framework honnête pour la décision :

Choisissez SolidJS quand :

  • Votre application a des mises à jour réactives haute fréquence (dashboards, plateformes de trading, collaboration en temps réel)
  • La taille du bundle est critique (widgets intégrés, micro-frontends, mobile-first)
  • Votre équipe est petite et disposée à investir dans l'apprentissage d'un nouveau paradigme
  • Vous voulez la réactivité fine-grained sans combattre le framework
  • Vous construisez quelque chose de nouveau et n'avez pas besoin d'un énorme écosystème de bibliothèque de composants

Choisissez React quand :

  • Votre équipe connaît déjà React (cela seul est généralement décisif)
  • Vous avez besoin d'un meta-framework mature (Next.js, Remix)
  • La disponibilité de bibliothèques tierces est importante
  • Vous embauchz et avez besoin d'un grand vivier de talents
  • Les exigences de performance de votre application sont typiques (pas extrêmes)

Pour nos projets de développement de CMS headless, React domine toujours parce que les intégrations CMS (Sanity, Contentful, Storyblok) ont des SDKs React de première classe. Le support Solid existe mais est souvent maintenu par la communauté.

Comparaison de code : modèles réels

Regardons certains modèles réels du projet côte à côte.

Récupération de données avec états de chargement

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>
  );
}

Le createResource de Solid avec Suspense est véritablement élégant. React a aussi Suspense (et c'est devenu mieux dans React 19), mais la version de Solid semblait plus naturelle à utiliser. Moins de boilerplate, moins de variables d'état à gérer.

Rendu conditionnel

React :

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

SolidJS :

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

Le composant <Show> de Solid existe parce que les ternaires ne fonctionnent pas de la même façon quand la fonction du composant ne s'exécute qu'une seule fois. Il a fallu s'y habituer, mais le modèle de callback vous donne une référence étroite et non nulle, ce qui est sympa pour TypeScript.

Rendu de liste

React :

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

SolidJS :

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

Le <For> de Solid n'a pas besoin de keys parce qu'il suit les éléments du tableau par référence. Quand un élément se déplace dans le tableau, Solid déplace le nœud DOM réel. React ferait un unmount et remount. C'est pourquoi la performance de liste de Solid est si bonne.

FAQ

SolidJS est-il prêt pour la production en 2026 ?

Oui. Solid 1.x a été stable pendant plus de deux ans. Des entreprises comme Cloudflare et Samsung l'ont utilisé en production. La bibliothèque de base est mature et bien testée. L'écosystème autour d'elle (SolidStart, bibliothèques de composants) est plus petit que celui de React mais en croissance régulière. La question n'est pas si Solid est prêt—c'est si les exigences de votre équipe et de votre projet s'alignent avec la taille de son écosystème.

Puis-je migrer de React à SolidJS progressivement ?

Pas facilement. Malgré la syntaxe JSX similaire, les modèles de runtime sont fondamentalement différents. Vous ne pouvez pas intégrer des composants Solid à l'intérieur d'une application React (ou vice versa) sans frontières iframe ou web component. Une migration serait essentiellement une réécriture. Si vous l'envisagez, commencez par une nouvelle fonctionnalité isolée ou un micro-frontend plutôt que d'essayer de convertir le code React existant.

SolidJS supporte-t-il le rendu côté serveur ?

Oui. SolidStart fournit SSR, streaming, et fonctions serveur. C'est fonctionnel et en amélioration rapide, mais en début 2026, c'est toujours moins mature que Next.js ou Remix. Pour les projets lourds en SSR, nous recommandions toujours d'évaluer Next.js ou Astro selon vos besoins en contenu.

Comment le compilateur de React 19 se compare-t-il à l'approche de Solid ?

Le compilateur de React 19 (anciennement React Forget) mémorise automatiquement les composants pour réduire les rendus inutiles. C'est une amélioration significative. Mais c'est toujours dans le modèle de React de réexécuter les fonctions du composant et différencier un VDOM. Solid saute les deux étapes entièrement. Le compilateur rend React plus rapide, mais ne change pas l'architecture fondamentale. Dans nos benchmarks, React 19 avec le compilateur était environ 30% plus rapide que React 18, mais toujours plus lent que Solid dans les scénarios riches en mises à jour.

Qu'en est-il de Preact Signals comme compromis ?

Preact Signals (et l'adaptateur @preact/signals-react) apporte la réactivité de type signal à l'écosystème React. C'est une approche intéressante, mais c'est combattre le modèle de base de React plutôt que de travailler avec. Nous l'avons brièvement testé et avons trouvé des cas limites avec Suspense et les fonctionnalités concurrentes. Si vous voulez des signals, Solid vous donne l'expérience complète sans l'inadéquation d'impédance.

SolidJS est-il plus difficile à apprendre que React ?

Si vous connaissez déjà React, l'API de Solid vous semblera familière—JSX similaire, modèles similaires. La partie difficile est de désapprendre le modèle mental de React. Vous rechercherez les modèles useEffect qui n'existent pas. Vous déstructurerez les props et briserez la réactivité. Vous essayerez les retours anticipés et vous demanderez pourquoi ils ne fonctionnent pas. Prévoyez environ 1-2 semaines pour qu'un développeur React expérimenté devienne productif en Solid, et encore un ou deux mois pour arrêter d'écrire du Solid saveur-React.

Quel framework a un meilleur support TypeScript ?

Les deux ont un excellent support TypeScript. Solid a un léger avantage parce que son compilateur peut fournir des types plus étroits dans certains modèles (comme le callback dans <Show>), et vous n'avez pas besoin du même volume de paramètres de type générique que certains hooks React complexes pourraient nécessiter. Mais honnêtement, les deux sont formidables. Ceci ne devrait pas être un facteur décisif.

Devrais-je utiliser SolidJS pour mon prochain projet ?

Cela dépend de vos contraintes. Si vous êtes une petite équipe construisant quelque chose sensible à la performance et vous êtes disposés à investir dans la courbe d'apprentissage et le contournement d'un écosystème plus petit, Solid est un choix véritablement excellent. Si vous avez besoin d'embaucher des développeurs React, d'utiliser des bibliothèques de composants établies, ou d'avoir un meta-framework éprouvé pour la production, React est le pari plus sûr. Il n'y a pas de réponse universelle—seulement la bonne réponse pour votre situation spécifique. Si vous voulez discuter de la décision pour votre projet, contactez-nous et nous pouvons vous aider à évaluer les compromis.