Cuándo elegir Solid y cuándo NO

Donde Solid brilla

Solid rinde al máximo cuando la interfaz es intensamente interactiva y el rendimiento del render importa de verdad. Su grano fino convierte en trivial lo que en otros modelos exige optimización constante.

La regla práctica: cuanto más cambie tu UI por segundo y más nodos independientes tenga, más se inclina la balanza hacia Solid. Una lista de mil filas donde cada celda tiene su propio valor es su terreno ideal, porque cambiar una celda toca un único nodo.

// Cada celda atada a su dato: actualizar una no recorre las otras 999.<For each={filas()}>  {(fila) => <Celda valor={fila.precio} />}</For>

El reverso también es cierto y conviene decirlo en voz alta: si tu “lista de mil filas” en realidad tiene veinte y cambia dos veces por minuto, esa ventaja no la va a notar nadie. Solid brilla cuando el rendimiento del render es un problema real y medible; inventarse uno para justificar la elección es tan poco riguroso como ignorarlo cuando de verdad existe.

Donde otra herramienta encaja mejor

La honestidad exige lo contrario: hay contextos donde elegir Solid sería remar contracorriente, y otra herramienta te dará más por menos.

Fíjate en el patrón: en tres de los cuatro casos, lo que decide no es una carencia técnica de Solid, sino el contexto —una plataforma (móvil), un recurso (talento disponible) o la naturaleza del proyecto (contenido)—. Solid pierde esas comparaciones por razones ajenas a su calidad como framework, y reconocerlo es justo lo contrario de descartarlo: es la condición para usarlo donde de verdad rinde.

Un vistazo comparativo antes del árbol de decisión; cada fila responde a una restricción distinta, no a un ranking absoluto de “mejor a peor”.

El árbol de decisión

La elección no se hace por preferencia estética, sino recorriendo restricciones de arriba abajo. Este árbol resume el criterio.

Léelo como una conversación con tus restricciones, no como una sentencia. La mayoría de proyectos reales tienen una restricción dominante —una plataforma obligada, un equipo con experiencia previa, un presupuesto de bytes— y esa restricción suele decidir más que cualquier diferencia de rendimiento en abstracto.

Conviven mejor de lo que parece

Presentar la elección como una guerra es un error de bulto: en 2026 estas herramientas se combinan con naturalidad. Astro puede hospedar islas de Solid y de React en la misma página; puedes incrustar un componente Solid en una app existente con una sola llamada a render; y el propio ecosistema converge, porque Svelte 5 adoptó reactividad de grano fino con sus runes y la propuesta de signals de TC39 empuja ese modelo hacia el estándar del lenguaje.

import { render } from "solid-js/web";import Widget from "./Widget";// Montar una isla de Solid dentro de cualquier pagina, sin tocar el resto.render(() => <Widget />, document.getElementById("panel"));

Esto habilita una estrategia realista y a menudo la más sensata: adoptar Solid por incrementos. No hace falta reescribir una aplicación entera para aprovechar su rendimiento donde más duele —la tabla que se congela, el editor que va a tirones, el gráfico que se repinta sesenta veces por segundo—. Aíslas ese fragmento crítico en una isla Solid, mides la diferencia, y dejas el resto del sistema exactamente como estaba. La decisión “Solid o no” rara vez es total: casi siempre es “¿dónde, dentro de este sistema, paga Solid su coste de aprendizaje?”.

En la práctica, esto convierte “qué framework elijo” en una pregunta menos dramática de lo que parece en los debates online. Rara vez apuestas el proyecto entero a una carta: eliges un default para el grueso de la aplicación y te reservas el derecho de meter una isla de otra tecnología donde tenga sentido. La pregunta madura no es cuál gana en abstracto, sino con cuál pierdes menos cuando te equivocas.