Modos del proyecto: SSR, SPA e islands

Los tres modos comparten tu app.tsx y tus rutas; lo que cambia es el reparto del trabajo entre los dos entornos. Verlos juntos, por lo que llega al navegador, aclara la diferencia antes de entrar en cada uno.

SSR: el modo por defecto

Con ssr en true —el valor por defecto— cada petición se renderiza en el servidor: SolidStart ejecuta tu árbol, produce el HTML de la página y lo envía al navegador, que lo pinta de inmediato y después lo hidrata con entry-client. El usuario ve contenido real en el primer viaje, antes de que el JavaScript cargue, y los buscadores reciben una página completa.

// app.config.tsimport { defineConfig } from "@solidjs/start/config";export default defineConfig({ ssr: true }); // el defecto explicito

El SSR de SolidStart transmite en streaming por defecto: en lugar de esperar a que toda la página esté lista, envía el HTML a trozos y deja que las partes asíncronas —envueltas en Suspense— lleguen cuando resuelven. Existen variantes de menor uso, un modo async que espera a tener la página entera antes de enviarla y un modo sync que no resuelve asincronía, pero el streaming es el que da el mejor tiempo hasta el primer byte y el revelado progresivo. Este es el modo recomendado para la mayoría de aplicaciones: SEO, primer pintado veloz y contenido que depende de cada petición.

El coste que SSR paga a cambio de esas virtudes es la hidratación: tu árbol corre dos veces, una en el servidor para escupir el HTML y otra en el cliente para reconectarle la reactividad sobre ese mismo DOM. Eso implica enviar al navegador el JavaScript de toda la página y volver a ejecutar su lógica de arranque, aunque buena parte del contenido sea estático. Solid mitiga ese coste con su grano fino —hidrata con precisión quirúrgica y sin reconciliar árboles—, pero el trabajo no es cero, y es justo ese trabajo el que el modo islands se propone recortar. Tenerlo presente evita idealizar el SSR: es el mejor modo por defecto, no un modo gratis.

El streaming, además, no es un detalle aislado: es la razón de ser de todo lo que aprendiste sobre Suspense, createAsync y las transiciones en los niveles de async. Cuando una parte de la página depende de un dato que aún viaja, su frontera de Suspense deja que el servidor envíe primero el resto del HTML y complete ese hueco en cuanto el dato resuelve, sin bloquear el primer byte.

// bajo SSR, esta frontera fluye en streaming: el resto de la pagina// se envia ya, y el panel llega cuando su dato resuelve<Suspense fallback={<Cargando />}>  <PanelDeDatos /></Suspense>

Lo que en el cliente veías como un patrón de carga elegante es, bajo SSR, el mecanismo que permite transmitir una página progresivamente. El modo por defecto y las primitivas de datos fueron diseñados para encajar; SSR es el escenario donde revelan su sentido pleno.

SPA: todo en el cliente

Poner ssr en false apaga el renderizado de servidor. El servidor —o un host estático— entrega entonces un shell mínimo, una página casi vacía cuyo contenedor se llenará en el navegador una vez que cargue y ejecute el JavaScript. Es el modelo clásico de aplicación de una sola página.

export default defineConfig({ ssr: false }); // modo SPA

El precio es visible: hay una ventana en blanco hasta que el bundle arranca, y los buscadores reciben poco que indexar. A cambio, ganas simplicidad de despliegue —una SPA puede vivir en un CDN estático sin proceso de servidor— y evitas por completo la complejidad de la hidratación y del código que debe correr en dos entornos. Sigue siendo un proyecto SolidStart de pleno derecho: conservas el enrutado por ficheros, el build y, si mantienes un servidor, incluso las funciones de servidor. Es la elección sensata cuando el SEO no importa y el primer pintado tampoco es crítico: paneles tras un login, herramientas internas, aplicaciones muy interactivas donde el contenido no es público.

Si necesitas algo de SEO sin renunciar a la SPA, aún puedes pre-renderizar rutas concretas a HTML en el build; pero cuando el SEO es central, esa misma necesidad es la señal de que en realidad querías SSR.

// una SPA puede congelar rutas concretas a HTML en el buildexport default defineConfig({  ssr: false,  server: { prerender: { routes: ["/", "/precios"] } },});

Islands: hidratación parcial

El tercer modo, todavía experimental, busca el mejor de los dos mundos para sitios dominados por contenido. En el modo islands, el servidor genera HTML estático para toda la página, pero solo las porciones marcadas como interactivas —las islas— envían y ejecutan JavaScript en el cliente. El resto de la página es HTML puro que nunca se hidrata, de modo que el navegador descarga y ejecuta drásticamente menos código.

export default defineConfig({  ssr: true,  // opcion experimental: activa el modelo de islas  experimental: { islands: true },});

El caso ideal son blogs, documentación, tiendas o páginas de marketing: mucho texto estático con unos pocos widgets vivos —un buscador, un carrito, un carrusel—. Frente a un SSR clásico, que hidrata la página entera aunque el noventa por ciento sea inerte, las islas hidratan solo lo que se mueve. En una página donde casi todo es contenido de lectura, esa diferencia se traduce en enviar una fracción del JavaScript y en un dispositivo modesto que responde antes, porque no gasta ciclos hidratando lo que nunca reaccionará. Al ser una función experimental, su API y sus límites pueden cambiar, así que hoy es una opción a vigilar y prototipar más que a construir un producto crítico encima; pero apunta a la dirección en la que se mueve todo el frontend, la de enviar cada vez menos JavaScript.

En términos del eje que abre esta lección, islands empuja el reparto hacia el servidor todo lo posible: renderiza allí la página entera y reserva el navegador para las chispas de interactividad. Es la apuesta más ambiciosa de las tres y también la menos asentada, así que hoy la eliges sabiendo que exploras terreno en movimiento y no que construyes sobre roca. Vigílala como se vigila el futuro: es probable que la dirección que marca —enviar cada vez menos JavaScript— acabe siendo la norma, aunque su forma concreta todavía cambie.

Qué eliges al crear la app

En la práctica, la primera bifurcación la tomas en el asistente de creación, cuando create-solid pregunta si quieres Server Side Rendering. Responder que sí deja ssr: true y te pone en el camino recomendado; responder que no fija ssr: false y arrancas en SPA. Islands no aparece ahí: se activa después en app.config.ts como la opción experimental que es. Y nada de esto es irreversible —cambiar de modo es, casi siempre, editar una clave de configuración—, pero conviene elegir con criterio desde el principio, porque el modo condiciona cómo escribes: en SSR piensas en qué corre en el servidor y qué en el cliente, en SPA vives solo en el navegador.

El consejo por defecto es nítido: empieza en SSR salvo que tengas una razón concreta para no hacerlo. Es el modo que mejor se porta con buscadores, con la percepción de velocidad y con contenido que cambia por usuario, y es donde las primitivas de datos rinden al máximo. Reserva la SPA para cuando el SEO sea irrelevante y el despliegue estático sea una ventaja real —una herramienta interna, un panel tras un login—, y trata islands como un experimento a seguir de cerca. Elegir SSR primero no te encierra: siempre puedes bajar a SPA con una clave, pero rara vez necesitarás el camino inverso.

Hay, por último, una consecuencia del modo que trasciende la configuración: moldea cómo programas cada componente. En SSR tu lógica corre en dos entornos, así que has de distinguir qué puede ejecutarse en el servidor y qué exige el navegador —de ahí que isServer y las funciones de servidor sean utensilios cotidianos—. En SPA esa dualidad se desvanece: todo es cliente, y con ella se van tanto la complejidad como las capacidades del servidor. El modo no es una casilla que marcas y olvidas; es el marco mental desde el que escribes.