Cuándo Solid NO es la elección correcta

Todo el track te ha mostrado por qué Solid es un modelo brillante. Esta lección hace lo contrario, y es la más adulta de todas: te enseña cuándo no usarlo. Porque la señal de un ingeniero senior no es defender su tecnología favorita, sino reconocer que la elección correcta depende de la restricción que domina el proyecto, y esa restricción rara vez es el rendimiento del render. Elegir la tecnología “aburrida” —la que el equipo ya sabe, la que tiene la librería que necesitas, la que nadie discutirá en tres años— es a menudo la decisión de arquitectura más sabia. Solid es excelente; no es siempre lo correcto, y saber distinguirlo es maestría.

El coste que no está en el benchmark

Un benchmark mide milisegundos de render. Un proyecto se paga en otra moneda, y son cuatro los costes que ningún gráfico refleja.

El primero es la contratación: hay órdenes de magnitud más desarrolladores de React que de Solid, así que un equipo Solid tarda más en crecer, cuesta más caro por experto y depende de menos personas —un riesgo de bus factor que no aparece en ningún benchmark—.

El segundo es el ecosistema: si tu producto necesita una librería concreta de tablas, gráficos, edición de texto rico, mapas o un SDK de auth que solo publica versión para React, ganar dos milisegundos de render no compensa reescribir esa pieza desde cero.

El tercero es la familiaridad: un equipo que ya piensa en React entrega antes en React, y el modelo de Solid —el componente que corre una vez, las props que no se destructuran— es una curva real que cuesta semanas de errores sutiles antes de rendir.

Y el cuarto es la longevidad: el respaldo institucional de React o Vue tranquiliza a una organización que planea mantener el código una década; el de Solid, más comunitario, es un riesgo que algunas no pueden asumir por política, no por ingeniería.

Fíjate en que los cuatro costes tienen algo en común: se pagan en personas y tiempo, no en CPU. Son exactamente la clase de coste que un benchmark no puede ver, porque no ocurre en la máquina sino en el equipo, en el mercado laboral y en el calendario. Ignorarlos porque no aparecen en un gráfico de rendimiento es el error de categoría más caro de la ingeniería de frontend.

flowchart TD
D[que restriccion domina el proyecto] --> P[rendimiento y DX de grano fino]
D --> T[equipo y contratacion]
D --> E[ecosistema y librerias concretas]
D --> R[riesgo y longevidad corporativa]
P -->|aqui Solid brilla| SI[elige Solid]
T -->|pool React enorme plazos cortos| NO[probablemente no Solid]
E -->|dependes de libs solo-React| NO
R -->|se exige una apuesta segura| NO
style SI fill:#a6e3a1,color:#11111b
style NO fill:#f38ba8,color:#11111b

Escenarios donde Solid pierde

Los criterios abstractos se vuelven nítidos en casos concretos. Un equipo grande de React con un plazo ajustado: introducir Solid añade una curva de aprendizaje y una tanda de refactors justo cuando lo único que importa es entregar; la tecnología aburrida, la que el equipo ya domina, gana sin discusión.

Una app atada al ecosistema de React: si compartes componentes con una app React Native, o dependes de una librería de UI empresarial, un editor de texto rico o un SDK que solo publican versión para React, la interoperabilidad pesa más que la elegancia del modelo. Reescribir esa pieza para ahorrar milisegundos de render es negativo en el balance.

Un sitio mayormente estático de contenido —un blog, una documentación, un marketing site—: ahí una SPA de Solid es sobreingeniería. Astro con islas entrega más rápido con menos JavaScript, y cuando de verdad hace falta interactividad puntual, incrusta una isla de Solid justo en ese punto sin cargar una SPA entera. La pregunta no es «qué framework de SPA», sino «¿necesito siquiera una SPA?», y muchas veces la respuesta honesta es que no.

---
// pagina .astro: HTML estatico por defecto, cero JavaScript...
import Buscador from "../components/Buscador"; // ...salvo esta isla de Solid
---
<article>{contenidoEstatico}</article>
<Buscador client:visible />   {/* solo ESTE trozo hidrata Solid */}

Una organización con procura conservadora: si la política exige tecnologías con respaldo corporativo demostrable, el mérito técnico de Solid no entra siquiera en la conversación —la decisión la toma un comité de riesgo, no un ingeniero—. En los cuatro escenarios, Solid no falla por malo: falla porque la restricción que manda no es la que Solid optimiza.

Conviene recordar, eso sí, que la elección rara vez es binaria. Si tienes una app React consolidada pero un widget concreto —una tabla de miles de filas, un editor en vivo— donde el grano fino de Solid marcaría la diferencia, Solid compila a custom elements, así que puedes incrustar esa isla dentro del React existente sin migrar nada.

import { customElement } from "solid-element";
// registra un widget Solid como elemento nativo, usable desde React, Vue o HTML plano
customElement("tabla-veloz", { filas: [] }, (props) => <TablaVeloz filas={props.filas} />);
// en el JSX de React: <tabla-veloz filas={datos} /> — Solid solo donde de verdad paga

La lección es que «no elegir Solid para la app» y «no usar Solid en ningún sitio» no son lo mismo: casi siempre existe un punto intermedio donde aplicas su fuerza sin pagar su coste de ecosistema en todo el proyecto.

El sesgo hacia lo nuevo

Hay una fuerza psicológica que empuja a elegir mal, y hay que nombrarla para resistirla: el sesgo hacia lo nuevo y lo elegante. Quien acaba de aprender Solid quiere usarlo, igual que quien compra una herramienta busca dónde clavarla.

El resume-driven development —elegir tecnología para tu currículum, no para el problema— disfraza ese deseo de criterio técnico, y es tanto más peligroso cuanto más brillante es el ingeniero, porque sabe construir buenos argumentos para lo que ya quería hacer. La inteligencia, usada para racionalizar una decisión ya tomada, no protege del error: lo blinda.

El antídoto es invertir la carga de la prueba. En vez de preguntar «¿por qué no usar Solid?», pregunta «¿qué restricción concreta de este proyecto hace que Solid sea mejor que la opción aburrida, y cuánto duele si me equivoco?». Si no sabes responder con una restricción real y medible, la respuesta honesta es la tecnología que el equipo ya mantiene. La novedad se justifica; no se presume.

Cómo decidir sin fanatismo

La decisión se reduce a una pregunta: ¿cuál es la restricción que domina este proyecto? Si es rendimiento de interacción con estado muy dinámico, DX de reactividad y un equipo capaz de absorber el modelo, Solid brilla y elegirlo es correcto. Si la restricción dominante es la velocidad de contratación, la dependencia de un ecosistema ajeno, la familiaridad del equipo bajo plazo, o una exigencia de longevidad institucional, entonces la mejor tecnología no es la mejor elección, y forzarla es un error de juicio disfrazado de rigor técnico.

// La decision no es un benchmark: es una funcion de coste ponderada
function elegirStack(p: Proyecto) {
  if (p.dependeDeLibsSoloReact) return "React";        // ecosistema manda
  if (p.equipoReact && p.plazoCorto) return "React";   // familiaridad manda
  if (p.sitioCasiEstatico) return "Astro + isla Solid"; // contenido manda
  if (p.politicaExigeRespaldo) return "opcion conservadora";
  if (p.interaccionMuyDinamica && p.equipoDispuesto) return "Solid"; // aqui brilla
  return "la que el equipo mantenga mejor";            // por defecto, lo aburrido
}

Pesa también la reversibilidad, y conviene hacerla explícita porque cambia el umbral de riesgo aceptable. Un prototipo de fin de semana o una herramienta interna que usarán diez personas son baratos de rehacer: ahí puedes gastar el token de innovación en Solid casi sin coste, aprender, y si no encaja, reescribir sin drama. Un core de negocio que vivirá cinco años y sobre el que trabajarán treinta ingenieros es lo contrario: cada decisión se amortiza y se hereda, así que la apuesta debe ser mucho más conservadora.

Cuanto más irreversible es la elección, más peso tienen los costes de gente y ecosistema frente a los de rendimiento, porque los primeros se pagan cada día durante años y el segundo se paga una vez. La madurez, en definitiva, es sostener sin contradicción dos cosas que el principiante cree opuestas: que Solid puede ser a la vez la tecnología superior y la elección equivocada para este caso concreto.

Aplícalo a un caso real para ver el método en acción. Imagina un panel de trading en tiempo real, con miles de celdas que parpadean cada milisegundo, construido por un equipo pequeño que puede aprender, para un producto propio y de larga vida. La restricción dominante es el rendimiento de actualización de grano fino, el equipo está dispuesto, y no dependes de ninguna librería solo-React: las cuatro señales apuntan a Solid, y elegirlo es de manual.

Cambia una sola variable y el veredicto se invierte. El mismo panel, pero el equipo son quince desarrolladores de React con un lanzamiento en ocho semanas y una librería de gráficos financieros que solo existe para React: ahora la restricción dominante ya no es el render sino la entrega y el ecosistema, y forzar Solid sería sacrificar el proyecto por la elegancia del modelo. Idéntico problema técnico, decisión opuesta, porque lo que cambió no fue la tecnología sino la restricción que manda.

Un último matiz, y no menor: la decisión casi nunca es tuya en solitario. Elegir un stack es un acto social —lo heredan quienes mantendrán el código, lo sufren quienes no lo eligieron, lo evalúa quien contrata—. Por eso la mejor elección técnica impuesta contra el consenso del equipo suele rendir peor que la segunda mejor adoptada con convicción por todos. Convencer, formar y construir acuerdo son parte de la decisión, no un trámite posterior a ella.