SolidJS vs React: reactividad granular explicada

Curso de SolidJS

Contenido del curso

No sé dónde empezar

Introducción a SolidJS

Reactividad a profundidad

Renderizado en Solid

Reactividad en Listas

Componentes

Cursos Empresas Blog Live Conf Eventos Precios

0:005:14

SolidJS vs React: reactividad granular explicada

Curso de SolidJS

Clase 1 de 27

Clase 1 / 27

Obtén respuestas inmediatas¿Dudas?Profundiza lo que acabas de ver

Recursos

SolidJS es la librería de JavaScript que está empujando a frameworks como React a repensar cómo manejan la renderización. Si te interesa entender por qué SolidJS aparece primero en los benchmarks de performance web, aquí vas a ver, con un ejemplo real, cómo su reactividad granular cambia las reglas del juego para desarrolladores frontend.

¿Qué hace diferente a SolidJS frente a React?

La diferencia está en cómo cada herramienta decide qué actualizar cuando algo cambia en pantalla.

React usa un virtual DOM y un algoritmo llamado reconciliación: cada vez que un estado cambia, revisa todo el árbol del DOM virtual para detectar qué elementos deben actualizarse. Suena lógico, pero en la práctica significa que incluso cambios pequeños obligan a reanalizar componentes enteros.

SolidJS, en cambio, aplica una reactividad granular. Esto quiere decir que solo actualiza el pedacito exacto del DOM que depende del dato que cambió. Nada más. Nada menos.

¿Qué es la reactividad granular? Es un sistema que rastrea las dependencias a nivel atómico, de modo que cuando un valor cambia, solo se re-ejecuta el código vinculado directamente a ese valor, sin tocar el resto del componente.

¿Cómo se comporta React al renderizar un to-do list?

Para comparar ambas librerías, Samuel Burbano construyó la misma aplicación de lista de tareas en React y en Solid [00:23].

En React, al iniciar la app, se valida todo el componente como parte del setup inicial. Un console.log muestra propiedades estáticas como el type de cada checkbox y propiedades dinámicas como el estado checked [00:45].

Lo interesante viene después. Cada vez que tocas algo, React necesita reconciliar el árbol completo:

Marcar o desmarcar un checkbox dispara una revalidación de toda la lista.
Cambiar el valor de un input fuera de la lista también obliga a reanalizar elementos que no dependen de ese estado [01:30].
Agregar o eliminar un ítem reevalúa absolutamente todo el DOM y la reactividad asociada [02:05].

Este comportamiento es la razón por la que React suele aparecer al final de los benchmarks cuando hay listas grandes, cambios de posición o eliminaciones frecuentes.

¿Por qué React reconcilia tanto?

Porque su modelo asume que es más seguro revisar todo el árbol que rastrear dependencias finas. Esa decisión simplifica la API, pero cobra factura en performance cuando la app crece.

¿Cómo resuelve SolidJS la renderización con su sistema reactivo?

Solid trabaja con una idea distinta: el componente es solo una función de inicialización o setup [02:35].

La primera vez que montas la app, Solid ejecuta el componente para configurar el DOM. A partir de ahí, no vuelve a correr esa función nunca más. Lo que se actualiza son las primitivas reactivas que están conectadas a nodos específicos del DOM.

En el ejemplo del to-do list pasa esto:

En la inicialización, Solid ni siquiera revisa las propiedades 100% estáticas como el tipo de elemento [03:00].
Cambiar el valor de un input externo no dispara revalidaciones en la lista [03:25].
Marcar un checkbox actualiza solo el estado de ese checkbox específico, nada más [03:40].
Eliminar un ítem remueve únicamente ese nodo, sin tocar el resto de la lista [03:55].
Agregar un ítem solo evalúa los estados reactivos del nuevo elemento [04:05].

¿Por qué SolidJS es más rápido que React en benchmarks? Porque actualiza el DOM a nivel atómico. Solo el nodo que depende del dato modificado se re-renderiza, evitando el costo de reconciliar árboles completos.

¿Qué es un componente de setup en SolidJS?

Es una función que corre una sola vez para describir la estructura inicial y conectar las dependencias reactivas al DOM. No se vuelve a ejecutar con cada cambio de estado, a diferencia de los componentes funcionales de React.

¿Qué vas a construir y aprender en el curso?

Vas a ir más allá de usar la herramienta: vas a construir una librería propia que te obliga a entender cada concepto desde dentro. Esa es la mejor forma de interiorizar cómo funciona la reactividad granular y por qué cada decisión de diseño importa.

Tu instructor es Samuel Burbano, senior software engineer con más de 12 años de experiencia en desarrollo web y contribuidor al core de SolidJS y a otros proyectos open source [04:35].

En las siguientes clases vas a trabajar con:

Las primitivas reactivas que implementa SolidJS y su impacto en proyectos reales.
El manejo de renderización condicional y sus diferentes facetas.
Técnicas de optimización para llevar tus aplicaciones al límite del performance.

¿Ya habías comparado el flujo de renderizado de React y Solid en un proyecto propio? Cuéntame en los comentarios qué diferencias notaste tú.