SolidStart: el meta-framework oficial de Solid

Solid, tal como lo has estudiado hasta aquí, es un renderizador reactivo excepcional y poco más: te da signals, un grafo de grano fino y componentes que corren una vez, pero no opina sobre cómo sirves HTML desde un servidor, cómo organizas tus rutas, cómo empaquetas para producción ni cómo despliegas en Vercel o Cloudflare. Un meta-framework es la capa que responde a todas esas preguntas a la vez. SolidStart es el meta-framework oficial de Solid —lo que Next es a React, Nuxt a Vue o SvelteKit a Svelte— y su rasgo definitorio es que apenas reinventa nada: se apoya en tres piezas maduras del ecosistema JavaScript y reserva su propio código para lo que solo Solid puede aportar. Entender esa arquitectura de capas es entender por qué SolidStart es a la vez delgado y capaz de desplegar en una docena de plataformas sin que cambies una línea de tu aplicación.

De Solid puro a un meta-framework

Cuando instalas solid-js y lo montas con Vite obtienes un renderizador de cliente: un árbol reactivo que vive en el navegador y pinta el DOM. Eso basta para una SPA de juguete, pero deja fuera todo lo que una aplicación de producción necesita alrededor. No hay convención para mapear URLs a componentes; no hay forma de renderizar en el servidor para que el primer byte ya lleve HTML; no hay un puente con tipos para ejecutar código de servidor desde el cliente; y no hay una historia de build que produzca, a partir del mismo código, un artefacto desplegable en Node, en un edge worker o en un bucket estático.

Un meta-framework es exactamente la pieza que aporta esas respuestas como convenciones y primitivas, no como decisiones que rehaces desde cero en cada proyecto. Y SolidStart adopta una filosofía deliberada al hacerlo: componer en vez de reinventar. En lugar de escribir su propio bundler, su propio servidor y su propio sistema de despliegue —el camino de los meta-frameworks de la generación anterior— se apoya en herramientas del ecosistema que ya resuelven cada problema por separado y aporta el pegamento más las primitivas específicas de Solid. El resultado es una base sorprendentemente pequeña para lo que hace.

Las tres capas: Vite, Nitro y Vinxi

Tres proyectos sostienen a SolidStart, y conviene saber qué hace cada uno, porque cuando algo falla el mensaje de error suele venir firmado por una de estas capas y no por SolidStart.

flowchart TD
APP[tu app Solid rutas y componentes] --> START[SolidStart convenciones y primitivas]
START --> VINXI[Vinxi orquesta los routers de build]
VINXI --> VITE[Vite compila el cliente y el JSX de Solid]
VINXI --> NITRO[Nitro servidor portable y presets de despliegue]
NITRO --> OUT[salida para Node Vercel Netlify Cloudflare Deno Bun estatico]
style START fill:#89b4fa,color:#11111b
style VINXI fill:#f9e2af,color:#11111b
style OUT fill:#a6e3a1,color:#11111b

Hay un detalle que delata esta arquitectura mejor que cualquier diagrama: los scripts de tu package.json.

{
  "scripts": {
    "dev": "vinxi dev",
    "build": "vinxi build",
    "start": "vinxi start"
  }
}

Cuando ejecutas npm run dev no arrancas SolidStart directamente: arrancas Vinxi, que a su vez levanta Vite para el cliente y Nitro para el servidor. SolidStart es, en buena medida, una configuración de Vinxi con las primitivas de Solid encima.

El reparto de trabajo entre las capas cambia según el momento. En desarrollo, Vite lleva la voz cantante: su servidor sirve tus módulos con recarga en caliente y Nitro se limita a atender lo que toca al servidor. En el build de producción, el foco se desplaza a Nitro: Vite compila los bundles y Nitro los empaqueta junto al servidor en el artefacto de .output que luego despliegas. Vinxi coordina esa transición para que tú veas un único comando —dev, build, start— sin orquestar a mano dos herramientas con ciclos de vida distintos.

Qué añade SolidStart sobre Solid

Si las capas de abajo son prestadas, cabe preguntarse qué es propiamente SolidStart. La respuesta: todo lo que conecta el mundo reactivo de Solid con ese servidor y ese build.

• Enrutado por ficheros: FileRoutes de @solidjs/start/router convierte src/routes/ en un árbol de rutas sin que declares tablas a mano.
• Renderizado isomorfo: SSR en streaming por defecto, con variantes async y sync, además de los modos SPA e islands.
• Funciones de servidor: la directiva "use server" marca código que solo corre en el servidor y se invoca desde el cliente como una llamada normal.
• Primitivas de datos integradas: query, createAsync, action y useSubmission, que ya viste asomar, encajan aquí con el ciclo de la petición.
• Entry points y documento: entry-client, entry-server y la envoltura HTML de la página.
• Configuración y despliegue: app.config.ts y los presets de Nitro.

Cada una de esas piezas es algo que en Solid puro tendrías que montar a mano. El enrutado, por ejemplo, deja de ser una tabla que mantienes y pasa a ser la forma de una carpeta: creas el fichero y la ruta existe.

// src/routes/sobre.tsx  ->  la URL /sobre, sin registrar nada
export default function Sobre() {
  return <h1>Sobre nosotros</h1>;
}

Pero el ejemplo más revelador es la función de servidor, porque es algo que Solid puro jamás podría dar solo:

// una funcion de servidor: SolidStart genera el transporte por ti
async function listarUsuarios() {
  "use server";
  // esto solo corre en el servidor: aqui si puedes tocar la base de datos
  return db.usuarios.findMany();
}

Desde un componente la llamas como a cualquier función asíncrona; por debajo, SolidStart la convierte en una petición al servidor cuando corre en el cliente y en una llamada directa cuando corre en el servidor. Ese puente solo puede darlo un meta-framework, porque necesita controlar a la vez el build del cliente y el del servidor —justo lo que Vinxi coordina—.

Ese puente, además, no vive aislado: se entrelaza con las primitivas de datos que ya estudiaste. query deduplica y cachea una petición por su clave dentro del alcance de la solicitud; createAsync la lee dentro del grafo reactivo; action y useSubmission cierran el círculo con las mutaciones.

// las primitivas que ya conoces, ahora sobre un servidor real
const getUsuario = query((id: number) => listarUsuario(id), "usuario");
const usuario = createAsync(() => getUsuario(props.id));

En Solid puro esas primitivas o no existen o dependen de que tú levantes el servidor a mano; en SolidStart encajan con el ciclo de vida de la petición y con el streaming del SSR, que es lo que las vuelve de verdad útiles. El meta-framework no solo añade piezas nuevas: le da a las que ya conocías el entorno donde por fin rinden.

Sobre qué se apoya el futuro

La arquitectura de capas no es estática. Vinxi nació para resolver un problema que Vite todavía no cubría bien: orquestar varios entornos de build —cliente, servidor, funciones— dentro de un mismo proyecto. Con la llegada de la Environment API de Vite y de la nueva generación de Nitro, buena parte de esa orquestación empieza a poder vivir en las propias herramientas, y el equipo de Solid trabaja en adelgazar o reemplazar la capa de Vinxi para apoyarse de forma más directa en Vite y Nitro.

Para ti, como autor de aplicaciones, el cambio será casi invisible: app.config.ts, las rutas por ficheros y las funciones de servidor son la superficie estable, y está pensada para sobrevivir a los cambios de fontanería de debajo. Conviene conocer los nombres —Vinxi, Nitro, Vite— para leer errores y seguir discusiones, pero tu código se escribe contra SolidStart, no contra ellos.

Esa estabilidad de la superficie es también lo que te permite invertir hoy en aprender SolidStart sin temer que el suelo se mueva: las convenciones que dominas son justo las que el equipo se ha comprometido a preservar mientras moderniza la fontanería. Y varias de ellas anticipan el rumbo de Solid 2.0, cuyo modelo asíncrono transparente encaja de forma natural con el streaming y las primitivas de datos que SolidStart ya explota. Aprender el meta-framework ahora es, en buena parte, adelantarse a cómo se escribirán las aplicaciones Solid en los próximos años.