El futuro del ecosistema: Solid Router, SolidStart y la convergencia

Cerramos el nivel mirando hacia afuera y hacia adelante. Solid no vive aislado: tiene un ecosistema propio —Solid Router, SolidStart— que ha sido, además, la incubadora de buena parte de lo que verás en 2.0. Y no compite en el vacío: el frontend entero está convergiendo hacia el modelo que Solid abrazó desde el primer día. Svelte 5 reescribió su reactividad con runes basadas en signals; Vue estrena Vapor mode y deja caer el virtual DOM; los signals se están estandarizando en el propio JavaScript. Esta lección sitúa a Solid en ese mapa con honestidad: qué caminos distintos llevan al mismo destino, y por qué el lugar de Solid es el de la referencia arquitectónica más que el del líder de cuota de mercado.

Solid Router y SolidStart: el ecosistema propio

Solid Router es más que un enrutador: ha sido el laboratorio donde el modelo de datos de 2.0 nació antes de bajar al núcleo. Ahí viven createAsync, query —con su deduplicación y revalidación— y las action para mutaciones; ahí se probó en producción la idea de leer datos como si fueran síncronos y dejar que lo pendiente aflore en las fronteras. Quien domina Solid Router ya escribe, sin saberlo, el código idiomático del futuro núcleo. Sus capacidades cotidianas —rutas anidadas, layouts, preload para adelantar datos en la navegación— son la cara visible de esa madurez.

SolidStart es el meta-framework que extiende los mismos primitivos al servidor. Se apoya en Nitro para el renderizado en servidor, el streaming y los presets de despliegue que lo llevan a decenas de plataformas sin cambiar tu código, y ofrece server functions con use server para escribir lógica de backend type-safe llamable desde el cliente. La promesa es la coherencia: la misma mentalidad reactiva y los mismos primitivos, del signal en la UI a la función en el servidor, sin cambiar de paradigma al cruzar la frontera.

// SolidStart: una server function type-safe, llamable desde el cliente
async function guardarNota(texto: string) {
  "use server";
  return db.notas.insert({ texto });
}

SolidStart tampoco impone un único modo de renderizado: la misma app puede servir unas rutas con SSR en streaming, otras como SPA en el cliente y otras prerenderizadas en el build, e incluso mezclar islands para hidratar solo lo interactivo. Esa flexibilidad por ruta, combinada con preload para adelantar los datos antes de que el componente se monte, es lo que convierte el modelo de datos del router en una experiencia de carga sin cascadas de principio a fin.

// La ruta declara su preload; los datos empiezan a viajar antes del render
export const route = {
  preload: ({ params }) => getNota(params.id),
};

Ese emparejamiento —el preload que dispara la petición y el createAsync que la lee como síncrona— es el patrón canónico de datos en SolidStart, y es exactamente el que 2.0 generaliza a todo el grafo. El meta-framework no es un añadido tardío sobre Solid: es donde su filosofía de datos se volvió una arquitectura completa. Las mutaciones cierran el círculo con action, que ejecuta en el servidor y revalida las consultas afectadas sin que orquestes la recarga a mano.

// SolidStart: una action revalida los datos leidos por createAsync
const crearNota = action(async (texto: string) => {
  "use server";
  await db.notas.insert({ texto });
});

La convergencia hacia los signals

El titular de esta década en frontend es que casi todos los frameworks están llegando, por caminos distintos, al lugar donde Solid ya estaba: reactividad de grano fino basada en signals y sin virtual DOM. No es imitación anecdótica; es convergencia estructural.

Conviene entender por qué ocurre ahora y no antes. Durante años, el virtual DOM fue el consenso porque resolvía un problema real —actualizar la interfaz de forma declarativa sin escribir mutaciones a mano— a un coste que parecía aceptable. Lo que cambió es que ese coste dejó de parecer aceptable: los dispositivos móviles de gama media hicieron visible el impuesto de reconciliar, los benchmarks lo cuantificaron sin piedad, y la alternativa —signals de grano fino— demostró que se podía tener la ergonomía declarativa sin el árbol virtual. Cuando una comunidad entera descubre que su impuesto era evitable, la migración es cuestión de tiempo. Solid no convenció a nadie con argumentos: convenció con una tabla de resultados que nadie podía ignorar y un modelo que, una vez visto, hacía difícil justificar el otro.

Svelte 5 reescribió su reactividad con runes: $state, $derived y $effect reemplazan la vieja magia del compilador —las asignaciones reactivas y el $:— por primitivos explícitos que son, en esencia, signals de grano fino. Svelte pasó de “reactividad por compilación opaca” a “reactividad por signals declarados”, exactamente el modelo de Solid, aunque expresado en su propio lenguaje de plantillas. Vue estrena Vapor mode, un modo de compilación que abandona el virtual DOM y genera actualizaciones directas al DOM apoyándose en su reactividad —ya basada en proxies con reactive y ref, parienta cercana de los signals—. Vapor acerca el rendimiento de Vue al de Solid en el benchmark precisamente eliminando lo que Solid nunca tuvo: el árbol virtual.

La cercanía se ve mejor lado a lado. Un $derived de Svelte y un createMemo de Solid expresan la misma idea —una derivación que se recalcula sola cuando cambian sus fuentes—; la diferencia es que el rune lo resuelve el compilador de Svelte y el memo es una función de runtime que puedes pasar como cualquier valor.

<!-- Svelte 5: runes, resueltas por el compilador -->
<script>
  let n = $state(0);
  let doble = $derived(n * 2);
</script>

// Solid: primitivos de runtime, funciones que puedes pasar y componer
const [n, setN] = createSignal(0);
const doble = createMemo(() => n() * 2);

Vue llega al mismo grano fino desde otra tradición: su reactividad por proxy, donde ref es un contenedor observable y reactive envuelve un objeto entero. En Vapor mode esas mismas fuentes actualizan el DOM directo sin pasar por un árbol virtual, exactamente el destino compartido.

// Vue: reactividad por proxy; en Vapor mode, sin virtual DOM
import { ref, computed } from "vue";
const n = ref(0);
const doble = computed(() => n.value * 2);

Y por debajo de todos, la propuesta de signals de TC39 busca llevar la reactividad de grano fino al propio JavaScript, con colaboración de autores de varios frameworks —Solid entre ellos—. Cuando el lenguaje tenga signals nativos, la reactividad dejará de ser una rareza de framework para volverse infraestructura de la plataforma, y la discusión se moverá de “qué framework tiene signals” a “qué framework los envuelve con la mejor ergonomía”.

flowchart TD
S[Solid grano fino sin VDOM desde el dia uno] --> D[destino comun signals sin arbol virtual]
SV[Svelte 5 adopta runes] --> D
VU[Vue estrena Vapor mode] --> D
TC[TC39 estandariza signals] --> D
style S fill:#89b4fa,color:#11111b
style D fill:#a6e3a1,color:#11111b

Comparativa honesta: mismo destino, distintos caminos

Que converjan no los vuelve iguales. Cada uno llega con un contrato y una ergonomía propios, y la elección sigue importando.

Las diferencias son reales y consecuentes. Los signals de Solid son funciones que puedes pasar, derivar y observar en tiempo de ejecución, sin lenguaje de plantillas ni magia de compilación; los runes de Svelte viven dentro de su compilador y su sintaxis de plantilla; la reactividad de Vue es por proxy, ergonómica pero con la trazabilidad más difusa que ya viste en createMutable. Solid es el único cuyo componente corre una vez y cuyo JSX compila a DOM real sin intermediarios. La convergencia iguala el qué —grano fino, sin VDOM— pero no el cómo, y ese cómo es lo que se siente al escribir código todos los días.

El lugar de Solid: referencia, no cuota

Aquí toca la honestidad que un profesional necesita. Solid no lidera en cuota de mercado ni de contratación: React domina por un margen enorme, Vue tiene un ecosistema vastísimo, Svelte una comunidad entregada. Solid es más pequeño en adopción, y elegirlo significa un ecosistema de librerías más reducido y menos talento disponible para contratar. Negarlo sería vender humo.

Pero hay otra vara de medir, y en esa Solid lidera claramente: es la referencia arquitectónica hacia la que el resto converge. Cuando Svelte adopta runes y Vue estrena Vapor y TC39 estandariza signals, están validando el modelo que Solid llevaba años encarnando en su forma más pura. La ventaja de Solid no es de tamaño sino de coherencia: el grano fino sin concesiones, el runtime más pequeño, el componente que corre una vez, y ahora el async dentro del grafo. Elegir Solid es elegir ese modelo en su expresión más limpia, a cambio de un ecosistema más chico. Es una decisión de restricciones —tipo de app, tamaño de equipo, apetito de riesgo— y no de moda, exactamente como debe ser toda elección técnica madura.

El riesgo, además, se puede acotar. Solid no exige un compromiso de todo o nada: se integra como isla dentro de Astro junto a otros frameworks, convive con componentes web, y su tamaño lo hace ideal para incrustar un fragmento reactivo veloz en una página por lo demás estática. Un equipo prudente puede probar Solid en un widget crítico de rendimiento —una tabla viva, un editor— sin reescribir su stack, medir el resultado en su propio contexto, y decidir con datos en vez de con fe. Esa adopción gradual es la respuesta madura a la tensión entre el modelo más limpio y el ecosistema más grande: no hay que elegir en abstracto, se puede probar en concreto.