Comparación honesta con el ecosistema

El eje que lo ordena todo: dónde vive el cambio

Hay una sola pregunta que separa a todos estos frameworks: cuando un dato cambia, ¿qué vuelve a ejecutarse? En un extremo, el re-render: React reejecuta el componente, produce un árbol virtual nuevo y lo reconcilia contra el viejo para hallar el mínimo cambio de DOM. En el otro, el grano fino: el signal que cambió notifica directamente a la computación que actualiza el nodo exacto, sin árbol intermedio ni comparación.

Solid nació en ese segundo extremo, y la noticia de la década es que casi todos se están moviendo hacia él. El motivo es económico: el coste del re-render —recalcular y comparar lo que no cambió— es real y crece con la app, mientras que el grano fino paga solo por lo que de verdad cambia. Cuando un modelo gana esa clase de argumento, el ecosistema termina imitándolo.

El mismo contador hace visible el eje. En React, el cuerpo del componente vuelve a correr entero en cada cambio, y el compilador solo evita recalcular lo que memoiza; en Solid, el cuerpo corre una vez y solo la interpolación se reevalúa.

// React: el cuerpo REEJECUTA en cada set; el compilador memoiza, no elimina el re-renderfunction Contador() {  const [n, setN] = useState(0);  console.log("cuerpo React"); // se imprime en cada actualizacion  return <button onClick={() => setN(n + 1)}>{n}</button>;}// Solid: el cuerpo corre UNA vez; solo la computacion de {n()} se reevaluafunction Contador() {  const [n, setN] = createSignal(0);  console.log("cuerpo Solid"); // se imprime UNA sola vez en toda la vida  return <button onClick={() => setN(n() + 1)}>{n()}</button>;}

Ese console.log es el experimento que zanja la discusión: en React se imprime en cada clic, en Solid una sola vez en toda la vida del componente. No es una diferencia de velocidad, es una diferencia de modelo mental, y de ella se derivan casi todas las demás —por qué en Solid no destructuras props, por qué no hay array de dependencias, por qué un useMemo no tiene equivalente necesario—.

Frente a frente, sin adornos

React es el gigante y su modelo es el re-render. React 19 y su compilador auto-memoizan para que no tengas que escribir useMemo y useCallback a mano, lo cual acerca la ergonomía a la de Solid —pero por debajo sigue reejecutando componentes y reconciliando árboles, solo que menos veces—. Donde Solid te da grano fino por diseño, React te lo aproxima con una capa de compilación sobre un modelo que sigue siendo de re-render.

Su fuerza, además, no es principalmente técnica sino gravitacional: el ecosistema más grande con diferencia, una reserva de talento inmensa y —esto sí es una ventaja de fondo— los React Server Components, cuyo modelo de servidor está hoy más maduro y más probado en producción que el de SolidStart. Si tu apuesta principal es una arquitectura server-first a gran escala, es honesto reconocer que React llegó antes y más lejos por ese camino.

Svelte 5 hizo el giro más llamativo: sus runes —$state, $derived, $effect— son signals con otro nombre, y abandonó el viejo modelo de invalidación por asignación. Compila a algo diminuto y su DX es exquisita. La diferencia con Solid es sutil pero de fondo: las runes de Svelte están atadas al compilador y a los archivos .svelte; los signals de Solid son valores de runtime, funciones que puedes crear, pasar, derivar y componer en cualquier módulo TypeScript, dentro o fuera de un componente. Svelte optimiza la escritura; Solid optimiza la composición.

// Solid: un signal es un valor de runtime; vive y viaja en cualquier modulo .tsexport function crearContador(inicial = 0) {  const [n, setN] = createSignal(inicial);  return { n, incr: () => setN((x) => x + 1) }; // se exporta, se pasa, se compone}// Svelte: $state solo existe dentro de la compilacion de un .svelte;// no puedes exportar una rune cruda desde un modulo .ts y reusarla igual.

Esa distinción no es académica: decide cómo testeas. La lógica de estado de Solid se prueba en un test de Node puro, sin renderizar nada, porque es solo funciones; la de Svelte suele necesitar montar el componente. Optimizar la escritura, como hace Svelte, y optimizar la composición, como hace Solid, son metas distintas que se pagan en sitios distintos.

Vue Vapor lleva la reactividad de Vue —ref, reactive, que siempre fue signal en espíritu— a un modo que compila fuera el virtual DOM, convergiendo visiblemente hacia el modelo de Solid. Vue gana en amplitud: dos modos de render, una API enorme, un ecosistema empresarial sólido y documentación de referencia.

Paga esa amplitud en superficie conceptual: más maneras de hacer lo mismo, la coexistencia de dos modos de render que mantener, y una reactividad potente pero con sus propias trampas de unwrapping de refs. Donde Solid apuesta por una sola idea llevada al extremo, Vue apuesta por cubrir todos los estilos, y cada apuesta tiene su público.

Qwik juega en otro eje. No compite en cómo propaga cambios —también usa signals— sino en cómo arranca: en vez de hidratar (reejecutar en el cliente lo que el servidor ya renderizó), resume, serializando el estado y el grafo para continuar donde el servidor lo dejó, con coste de arranque casi constante sin importar el tamaño de la app. Solid hidrata; Qwik reanuda. Para una app enorme donde el time-to-interactive manda, la resumabilidad de Qwik es una respuesta distinta a una pregunta que Solid contesta con hidratación en streaming.

Qué hace único a Solid

Lo que ningún otro reúne a la vez es la tríada: signals que son valores de runtime componibles como funciones planas, un compilador que convierte el JSX en creación de DOM real sin runtime de VDOM, y un árbol de ownership que ata y libera recursos solo.

Cada rival tiene alguna pieza, ninguno las tres. React tiene ergonomía JSX pero no grano fino nativo; Svelte tiene grano fino pero atado al compilador y a su formato de archivo; Vue converge hacia el grano fino pero carga una API amplia y dos modos; Qwik optimiza el arranque en un eje distinto. Solid es el único que te da el JSX y el TypeScript que ya conoces sin re-render, con signals que viajan fuera de los componentes y una limpieza que nunca escribes. La firma no es ninguna pieza suelta —hoy todas están repartidas— sino su combinación exacta.

Esa composición fuera del componente es la ventaja más infravalorada. Como un signal es solo una función, puedes fabricar lógica de estado en un módulo neutro, testearla sin montar nada, y compartirla entre componentes o incluso frameworks. Es la misma propiedad que hace que los primitivos de la comunidad se encadenen como funciones puras: el modelo no tiene costuras entre «dentro» y «fuera» del árbol.

// store.ts: estado compartido en un modulo neutro, sin ceremoniaconst [sesion, setSesion] = createSignal<Usuario | null>(null);export const usuario = sesion;                       // getter de solo lecturaexport const entrar = (u: Usuario) => setSesion(u);  // dos componentes lo consumen// Header.tsx y Perfil.tsx importan `usuario` y reaccionan sin provider ni hook:// el mismo signal, leido desde cualquier sitio, mantiene su reactividad intacta.

Ningún otro framework te da exactamente esto: en React necesitarías un contexto o una store externa; en Svelte, la rune no sale del componente sin envoltura; en Solid, el estado compartido es un módulo que exporta funciones, y ya está.

Dónde flaquea de verdad

Y ahora la parte que un fan omitiría. Solid es más pequeño en todo lo que no es rendimiento: menos librerías —a veces la de gráficos, tablas o auth que necesitas solo existe para React—; menos talento disponible —contratar un experto en Solid es más difícil que en React—; un meta-framework más joven que Next.js, con menos features de nicho y menos batallas de producción ganadas; y menos respaldo corporativo, lo que para algunas organizaciones es un riesgo de longevidad que no pueden asumir.

Ese déficit de ecosistema es concreto, no abstracto. Llega el día en que necesitas una tabla virtualizada con edición en línea, o un SDK de pagos, o un editor de texto rico maduro, y descubres que en React hay tres opciones probadas y en Solid ninguna del todo lista. Puedes envolver la versión vanilla con un primitivo —el track te enseñó cómo—, pero eso es trabajo que en React ya estaría hecho. La superioridad del modelo no rellena ese hueco.

Su curva de entrada es real y específica: «el componente corre una vez» y «no destructures props» tumban a quien llega con los reflejos de React, y esos tropiezos cuestan semanas de bugs sutiles antes de que el modelo encaje. Nada de esto es un defecto técnico; es el precio de ser el mejor modelo con la comunidad más pequeña, y fingir que no existe es el error de todo entusiasta.