Next.js está en declive. Conoce a Vike.

Los desarrolladores de React siguen describiendo la misma sensación inquietante: su aplicación Next.js parece lenta incluso antes de volverse grande. Haces clic en un enlace en localhost y esperas de 1 a 2 segundos para que el servidor de desarrollo responda, la sustitución en caliente de módulos se interrumpe, y cada cambio se siente como empujar código a través de melaza en lugar de iterar en tiempo real.

Ese arrastre no se trata solo de percepción; proviene del peso y la ambición del marco. Next.js intenta ser tu enrutador, empaquetador, tiempo de ejecución del servidor, capa de datos e historia de implementación todo a la vez, y cada capa de "conveniencia" se interpone entre tú y el navegador, añadiendo sobrecarga tanto a los tiempos de construcción como a los ciclos de retroalimentación.

El diseño todo en uno también incorpora una manera muy específica de construir aplicaciones React. El enrutamiento basado en el sistema de archivos, las rutas de API, los componentes del servidor, las convenciones del enrutador de la aplicación y las configuraciones de implementación centradas en Vercel crean un conjunto ajustado de suposiciones que funcionan de maravilla para un blog o una página de aterrizaje, pero empiezan a resultar restrictivas cuando necesitas flujos de datos no convencionales o infraestructuras personalizadas.

Una vez que te adhieres a esas opiniones, retractarte se vuelve costoso. ¿Quieres cambiar el enrutamiento, experimentar con una estrategia de renderizado diferente o introducir gradualmente otra pila de interfaz de usuario? Con Next.js, a menudo te enfrentas a reescrituras completas, soluciones frágiles o un laberinto de configuraciones que aún luchan contra las opciones predeterminadas del marco.

Los desarrolladores están descubriendo esto como un compromiso a contrarreloj. Te mueves rápido para el MVP, pero a medida que la aplicación crece hacia un panel multi-inquilino o un SaaS complejo, las mismas abstracciones que parecían mágicas se convierten en fricción: construcciones más lentas, paquetes más grandes y patrones que resisten la refactorización.

Esa fricción también se refleja en el código enviado. Los paquetes típicos de Next.js para páginas no triviales fácilmente alcanzan el rango de 70 a 100 kB antes de añadir bibliotecas de UI serias, mientras que configuraciones más ligeras suelen mantenerse en la banda de 10 a 15 kB, lo que afecta directamente los tiempos de carga, el Tiempo hasta la Interacción y las puntuaciones de Lighthouse.

La experiencia del desarrollador se ve afectada junto con el rendimiento. Los largos tiempos de inicio en desarrollo, los errores opacos en lo profundo de la pila del framework y el cambio constante debido a cambios importantes en las funciones, como los Componentes del Servidor de React, se combinan para generar una sensación de que el framework, y no tu producto, domina tu día.

Por eso, una nueva generación de herramientas, incluyendo Vike sobre Vite, está enfocándose explícitamente en esta pesadez—prometiendo paquetes más pequeños, retroalimentación más rápida y menos dependencia sin obligarte a abandonar el ecosistema de React.

Conoce a Vike, un meta-framework modular que se basa en Vite y apunta explícitamente al espacio que Next.js ha dejado. En lugar de un monolito que dicta el enrutamiento, la obtención de datos y el despliegue, Vike se centra en una sola tarea: conectar SSR, SSG y el enrutamiento al servidor de desarrollo y al empaquetador ultrarrápido de Vite.

Nacido en 2021 como `vite-plugin-ssr`, Vike evolucionó en silencio mientras los desarrolladores de React discutían sobre routers de aplicaciones y componentes del servidor. Un cambio de marca en 2023 le otorgó una identidad más clara, y desde entonces ha superado las 5,000 estrellas en GitHub, lo que indica que ya no se trata de un experimento de fin de semana, sino de un marco con una atracción real.

La filosofía central de Vike se siente casi reaccionaria en 2025: ser sin opiniones, mantenerse con licencia MIT y evitar reescrituras impulsadas por el hype. Los mantenedores la presentan como “aburrida de una buena manera”: una herramienta que cambia lentamente, favorece la configuración explícita y te permite traer tu propio stack para datos, autenticación y estado en lugar de obligarte a seguir un único camino privilegiado.

Mientras que Next.js se apega estrictamente a convenciones impuestas — `app/` frente a `pages/`, rutas basadas en archivos, acciones del servidor, Componentes del Servidor de React — Vike reduce las cosas a lo básico. Tú defines rutas, configuraciones de páginas y modos de renderizado por ti mismo, y luego eliges características como SSR, SSG o renderizado solo del cliente página por página con simples booleanos y archivos de configuración.

Ese modelo mínimo y opcional se extiende a la capa de interfaz de usuario. A Vike no le importa si usas React, Vue o Solid; el mismo proyecto puede mezclar estos como “islas” en una sola página sin adaptadores ni envolturas. Obtienes ganchos de bajo nivel y bloques de construcción, no un marco que insista en que cada componente hable los Componentes del Servidor de React o viva en un árbol de directorios preestablecido.

Los desarrolladores frustrados con los frecuentes cambios disruptivos de Next.js y su alineación constante con un proveedor de alojamiento ven la contención de Vike como una característica, no como un error. Sin optimizador de imágenes integrado, sin capa de datos mágica, sin rutas API propietarias: solo Vite, enrutamiento y primitivas de SSR que se mantienen al margen mientras ensamblas el resto de la pila por ti mismo.

Los puristas de React quizás quieran apartar la vista, porque el truco más subversivo de Vike es que deja de preocuparse por qué framework de interfaz de usuario usas. Su enrutamiento, carga de datos y canalización de renderizado se sitúan por debajo de la capa de componentes, por lo que la interfaz se convierte en un conjunto de "islas" que pueden provenir de React, Vue, Solid, o cualquier otra cosa que Vite pueda compilar.

En la demostración de Better Stack, la página Acerca de funciona como una ruta estándar de React, pero la sección de habilidades en el medio de esa página es un componente de Vue. Sin iframe, sin microfrontend shell, sin capa de adaptador personalizada, simplemente una isla de Vue montada directamente en una página de React con sin envolturas, sin trucos.

Ese modelo de isla suena académico hasta que piensas en micro-frontends. Vike permite a los equipos dividir una aplicación en partes implementadas de forma independiente, de modo que un equipo puede lanzar un panel de Vue, otro puede mantener un checkout legacy de React y un tercero puede experimentar con Solid para un widget de alta interacción, todo dentro de un mismo espacio de URL.

Las plataformas multi-tenant se benefician aún más. Un SaaS que ofrece dashboards en marca blanca para docenas de clientes puede alojar: - Herramientas de administración basadas en React - Analíticas centradas en Vue para un cliente específico - Widgets en tiempo real impulsados por Solid

Todo en una sola aplicación Vike, sin necesidad de implementaciones separadas o forzar a cada inquilino a utilizar la misma infraestructura.

Las migraciones graduales finalmente parecen sensatas aquí. En lugar de una reescritura abrupta y total, un equipo puede reemplazar una página de Next.js React pieza por pieza: reimplementar una sola sección como una isla de Vue o Solid, validarla en producción y luego expandir el área de impacto. Los hooks de bajo nivel de Vike mantienen SSR, hidratación y enrutamiento consistentes mientras la capa de UI evoluciona.

Next.js simplemente no facilita esto. Su modelo mental completo, desde el enrutamiento basado en archivos hasta la recuperación de datos y los Componentes de Servidor de React, asume React en todas partes, todo el tiempo. Mezclar Vue o Solid en un árbol de Next.js generalmente significa trucos frágiles de webpack, construcciones separadas, o micro-frontend completamente desarrollados con toda la sobrecarga operativa que ello implica.

Vike, en contraste, se apoya en el ecosistema de Vite y trata los frameworks como complementos en lugar de una religión. La página de GitHub del proyecto, [vikejs/vike: [alternativa a Next.js/Nuxt] El composable ... - GitHub](https://github.com/vikejs/vike), publicita explícitamente islas independientes de frameworks y "una flexibilidad sin precedentes" como objetivos de primer nivel.

Para equipos que se enfrentan a una migración de varios años, una adquisición desordenada o un portafolio de frontends desajustados, esa flexibilidad no es un truco de salón. Es una forma de seguir entregando mientras tu pila tecnológica se pone al día con la realidad.

El tamaño del paquete cuenta la historia. En la demostración de Better Stack, las páginas de Vike envían rutinariamente paquetes de cliente en el rango de 10–15 kB, mientras que las páginas comparables de Next.js se inflan a 70–100 kB+ antes de agregar código de la aplicación real. Esa diferencia de 5–10 veces no es un error de redondeo; redefine la velocidad a la que tu interfaz de usuario se muestra y responde.

Vike logra esto al montar directamente sobre Vite en lugar de superponer su propio sistema de construcción. Los módulos ES nativos de Vite, la pre-bundling y el servidor de desarrollo hacen que la sustitución de módulos caliente se sienta casi instantánea, no "espera dos segundos y espera". Verás los cambios reflejados en un instante, incluso a medida que tu proyecto crece más allá de un estado de juguete.

Next.js, por el contrario, arrastra un mayor tiempo de ejecución, más abstracciones y mucho JavaScript del cliente por defecto en cada ruta. Pagas por el enrutamiento, los hooks de datos y la integración de los componentes del servidor de React, ya sea que los uses o no. Ese impuesto base es la razón por la que una aplicación "hello world" en Next ya pesa decenas de kilobytes en el navegador.

Los paquetes más pequeños significan menos JavaScript para descargar, analizar y ejecutar, lo que reduce directamente el Tiempo hasta el Primer Byte (TTFB) y el Tiempo hasta la Interactividad. Un paquete de 15 kB a menudo llega en un solo viaje de red, especialmente en HTTP/2, y se analiza en milisegundos en teléfonos de gama media. Un paquete de más de 100 kB tiene que enfrentarse al ancho de banda, la latencia y CPUs más lentas antes de que los usuarios puedan interactuar con algo.

El diseño de Vike mantiene la carga del navegador centrada en tu interfaz de usuario, no en la maquinaria del framework. Solo envías las islas y componentes que realmente se ejecutan en el cliente, en lugar de un contenedor de aplicación monolítica. No hay enrutador del lado del cliente automático si no lo necesitas, ni lógica de hidratación para páginas que se renderizan correctamente como HTML estático.

Esa filosofía también hace que el rendimiento sea más predecible. Cuando agregas una nueva función, puedes ver exactamente qué módulos afectan al paquete del cliente y en qué medida, gracias a la salida de construcción transparente de Vite. La optimización del rendimiento se convierte en un proceso de ajuste de las dependencias reales, no en una exploración de los internals de los frameworks que nunca solicitaste.

Next.js te pide que compres su forma de ver el mundo. Obtienes convenciones como `getServerSideProps` y `getStaticProps`, enrutamiento automático y React Server Components integrados, pero también heredas un montón de comportamientos invisibles: cuándo se cargan los datos, cómo se almacenan en caché, dónde se ejecuta el código. Una vez que tu aplicación deja de parecer un blog, esa "magia" se convierte en algo que depuras en lugar de beneficiarte de ello.

Vike va en la otra dirección y te entrega el cableado. El modo de renderizado se convierte en una bandera de configuración explícita en cada página (`ssr: true` o `false`), así que decides qué rutas se pre-renderizan, cuáles se hidratan y cuáles permanecen solo en el servidor. Sin cascadas ocultas, sin que el marco adivine tu intención a partir de un nombre de archivo.

La obtención de datos en Vike se asemeja más a TypeScript regular que a un ritual de marco. En lugar de funciones especiales del ciclo de vida, utilizas ganchos de bajo nivel y un patrón llamado Telefunc para definir funciones del servidor en archivos `.ts` y llamarlas directamente desde el cliente. Vike se encarga de la serialización y el enrutamiento en segundo plano, pero te deja el control total sobre cuándo y cómo obtienes los datos.

Telefunc esencialmente reemplaza las rutas de API para la mayoría de los casos de uso. Escribes algo como `addEntry()` en un archivo de Telefunc, importas un cliente generado en el frontend y llamas a `await addEntry(...)` con una tipificación completa de extremo a extremo. Sin `pages/api`, sin código base de REST, sin una capa adicional de GraphQL a menos que lo desees.

Debido a que Telefunc solo expone funciones, se integra bien con las herramientas existentes. Puedes envolver las entradas en esquemas Zod para la validación en tiempo de ejecución, y luego inferir tipos de TypeScript a partir de esos esquemas sin coste alguno. Eso te proporciona una única fuente de verdad para los contratos de datos en lugar de tener que manejar DTOs, controladores de API y tipos de cliente.

Vike también se mantiene al margen de tu estrategia de caché. ¿Quieres emparejar Telefunc con TanStack Query? Colocas tus llamadas de Telefunc dentro de `useQuery` o `useMutation`, configuras los tiempos de caducidad y los reintentos, y tienes una capa de datos completamente personalizada que aún se siente como un React idiomático. Sin pelear con una caché a nivel de marco que insiste en volver a validar o volver a obtener datos en momentos inoportunos.

Los equipos experimentados tienden a apreciar ese tipo de explicitud. Si ya sabes cómo quieres manejar la autenticación, el manejo de errores y la normalización de datos, el stack todo incluido de Next.js puede sentirse como rieles soldados al marco. El enfoque de Vike significa más decisiones desde el principio, pero tú te haces cargo de cada una.

La propiedad importa cuando tu aplicación supera la meta actual. Con Vike, tu arquitectura es solo TypeScript, Vite y las bibliotecas que elegiste, no una caja negra que podría cambiar su modelo de datos el próximo año. Para los equipos que han sufrido por cambios disruptivos y comportamientos ocultos, “tu aplicación, tus reglas” no es un eslogan; es gestión de riesgos.

Photon es la parte de Vike que responde de manera silenciosa la pregunta más difícil en los modernos frameworks web: ¿dónde se ejecuta realmente esto? Presentado como una herramienta de despliegue en lugar de otro runtime más, Photon empaqueta tu aplicación Vike para que se instale sin problemas en plataformas de edge como Cloudflare Workers y Vercel, sin necesidad de un ritual de DevOps personalizado para cada objetivo.

En lugar de enviar un robusto servidor Node, Photon compila tus rutas en pequeñas funciones amigables con el borde. Esto se alinea con toda la narrativa de Vike de "paquetes pequeños, área de superficie pequeña": JavaScript mínimo en el cliente, sobrecarga mínima en el servidor y ningún proceso monolítico inactivo en una región que no elegiste.

El resultado es exactamente lo que los proveedores de edge han prometido durante años: sin inicios en frío y un TTFB muy bajo. Los workers se despliegan cerca de los usuarios, Vike transmite HTML rápidamente y evitas la penalización de 300 a 800 ms que conlleva iniciar un servidor Node tradicional, especialmente en rutas de bajo tráfico o configuraciones multirregión.

Photon también intenta normalizar el caos de las plataformas en el borde. En lugar de aprender las particularidades de Cloudflare, las reglas de tiempo de ejecución de Vercel y las trampas del sistema de archivos de cada proveedor, configuras Vike una vez y dejas que Photon emita los artefactos y adaptadores correctos según el objetivo.

Eso sitúa a Vike firmemente en el campamento que prioriza el edge, junto a Remix y SvelteKit, que ya se apoyan en entornos de ejecución distribuidos para lograr velocidad. La diferencia es filosófica: Vike se mantiene más cerca de Vite y de los primitivos SSR clásicos, mientras que Photon se encarga de la traducción final a entornos al estilo Workers.

El despliegue en el borde se está convirtiendo rápidamente en un requisito básico para los frameworks de la era React. Guías como Las 5 mejores alternativas a Next.js para desarrolladores de React - LogRocket Blog tratan cada vez más "se ejecuta en el borde" como un ítem de verificación, no como un beneficio, y Photon es la respuesta de Vike a esa expectativa.

Para los equipos atrapados entre las suposiciones centradas en Vercel de Next.js y las configuraciones de SSR de Vite DIY, Photon convierte a Vike en una opción creíble y lista para producción que realmente pertenece al borde global.

El mayor punto de venta de Vike—el control—también se convierte en su mayor desafío. No obtienes la comodidad de “baterías incluidas” que convirtió a Next.js en la respuesta predeterminada de React para startups y agencias. Vike te proporciona primitivas y espera que tú ensamblar un marco, no solo un proyecto.

Fuera de la caja, no encontrarás el conjunto de comodidades que los desarrolladores de Next.js dan por sentadas. No hay un pipeline de optimización de imágenes integrado, ninguna solución de autenticación de primera parte, ninguna capa de rutas API con opiniones definidas, y ninguna analítica oficial, fuentes o pilas de middleware. Tú mismo debes configurar cosas como las cargas de archivos, la limitación de tasas y la caché, generalmente eligiendo bibliotecas de terceros.

Esa modularidad se siente poderosa solo si ya sabes qué piezas quieres. Para muchos equipos, la falta de un ecosistema de presets duele más de lo que ayudan las mejoras de rendimiento en bruto. Intercambias la experiencia de "integrar un plugin y listo" de Next.js por leer documentación y combinar herramientas como TanStack Query, Zod y tus propias convenciones de enrutamiento.

Next.js también supera a Vike en gravedad comunitaria. Next tiene miles de tutoriales, respuestas en Stack Overflow y estudios de caso en producción; Vike tiene un puñado de publicaciones en blogs, un Discord más pequeño y ejemplos dispersos en GitHub. Cuando te encuentras con un caso límite raro de SSR o un error de implementación, es menos probable que pegues un error en una barra de búsqueda y encuentres una solución lista para usar.

Ese ecosistema más pequeño se traduce en menos integraciones pulidas. No verás un mercado de adaptadores oficiales para cada CMS sin cabeza, proveedor de autenticación y pasarela de pago. En su lugar, estarás conectando servicios como Auth0, Clerk o Stripe de forma manual, decidiendo cómo fluyen los tokens a través de las funciones del servidor y cómo hidratas el estado en el cliente.

Los equipos enfocados en React enfrentan otra dificultad: React Server Components aún no están completamente listos. Vike puede aproximarse al patrón con funciones del servidor y hidratación selectiva, pero no se obtiene la narrativa fluida de RSC en la que se apoya Next.js 13+. Si ya estás invertido en patrones RSC, diseños y transmisión, actualmente Vike se siente como un paso lateral, no hacia adelante.

Vike básico se siente empoderador hasta que te das cuenta de que ahora posees todo. Esa libertad de elegir tu enrutador, tu capa de datos, tu estrategia de caché y tu pila de autenticación también significa un costo de configuración inicial más alto y una factura de mantenimiento continuo que solía ser un problema de Next.js, no tuyo.

Los desarrolladores que están acostumbrados a `create-next-app` se llevan una sorpresa desagradable cuando un proyecto de Vike comienza siendo poco más que enrutamiento, primitivas de SSR/SSG y algunos archivos de configuración. Tú eliges cómo estructurar las páginas, dónde colocar las llamadas a la API y cómo manejar la invalidación de caché, lo que ralentiza los proyectos desde cero que solo necesitan ser entregados.

El video menciona la curva de aprendizaje como "un poco de broma" precisamente porque Vike se niega a ocultar la complejidad. Tú mismo conectas la obtención y el almacenamiento en caché de datos con hooks, en lugar de dejar que la lógica se maneje en `getServerSideProps` o `getStaticProps`, permitiendo que el marco orqueste todo.

La documentación amplifica ese dolor una vez que te desvías del camino feliz. La SSR básica y el enrutamiento se sienten lo suficientemente claros, pero las configuraciones avanzadas de React, las islas de múltiples marcos y los patrones específicos de los bordes todavía tienen documentación irregular, obligando a los desarrolladores a desensamblar ejemplos o buscar en los problemas de GitHub.

Esa flexibilidad en torno a los datos muestra ambas caras de la moneda. ¿Quieres TanStack Query, envoltorios de fetch personalizados o una capa RPC desarrollada internamente? Vike se mantiene al margen, pero también se niega a ofrecerte una solución aprobada, lista para usar, en la que un equipo pueda estandarizarse por defecto.

Cada proyecto serio termina montando su propia pila para:

• 1Obtención y almacenamiento en caché de datos
• 2Autenticación y sesiones
• 3Optimización de imágenes y gestión de activos
• 4Límites de error y observabilidad

La propiedad también implica hacerse cargo de los aspectos difíciles. El video menciona desajustes de hidratación recurrentes en aplicaciones con mucho React y peculiaridades de TypeScript que nunca verás en Next.js porque el framework de Vercel ha pasado años puliendo esos detalles.

Los equipos que migran de las pulidas herramientas de Next.js al toolbox abierto de Vike sienten esa fricción con más intensidad. Cambias los límites y la experiencia de desarrollo integrada por un control en bruto, y las primeras semanas pueden sentirse menos como un aumento de productividad y más como ingeniería de frameworks a puño desnudo.

Elegir entre Vike y Next.js comienza con una pregunta directa: ¿estás optimizando para los próximos tres meses o para los próximos tres años? Los plazos cortos y los requisitos difusos favorecen la convención y las soluciones integradas. Los sistemas de larga duración con restricciones en evolución recompensan el control explícito y la composabilidad.

Vike brilla cuando la arquitectura importa más que la velocidad de los andamios. Los equipos que planifican plataformas a multi-año, SaaS multi-inquilino o configuraciones de micro-frontend se benefician de sus islas independientes de marco, pequeños paquetes de 10-15 kB y conmutadores de SSR/SSG por página. Intercambias ergonomía instantánea por un sistema que se adapta en lugar de romperse cuando cambian los requisitos.

Los micro-frontends y las reescrituras graduales son donde Vike se siente injusto. ¿Necesitas ejecutar React para tu panel, Vue para un administrador heredado y Solid para un nuevo experimento de marketing en el mismo dominio o incluso en la misma página? Los ganchos de bajo nivel y la capa de enrutamiento de Vike te permiten unir todo eso sin las limitaciones de "un marco para gobernarlos a todos" que hacen que movimientos similares en Next.js sean dolorosos.

Los equipos obsesionados con el rendimiento también tienen un fuerte argumento a favor de Vike. Si tus presupuestos exigen cargas iniciales de menos de 20 kB, renderizado en el borde a través de Photon en Cloudflare Workers o Vercel, y un mínimo sobrecarga de hidratación, el núcleo ágil de Vike y el HMR impulsado por Vite te ofrecen más margen que un paquete típico de Next.js de 70 a 100 kB. Tú controlas los compromisos en lugar de heredarlos.

Next.js sigue siendo la mejor opción cuando necesitas lanzar algo de forma urgente. Para MVPs rápidos, sitios de marketing con mucho contenido y paneles de control que dependen de Markdown, integraciones de CMS y optimización de imágenes, sus características integradas reducen la fatiga de decisiones. Obtienes enrutamiento basado en archivos, rutas API, manejo de imágenes y Componentes de Servidor de React sin tener que montar una pila desde cero.

Los equipos que están muy invertidos en el ecosistema de Vercel deberían pensarlo dos veces antes de saltar. Si sus flujos de trabajo ya dependen de las vistas previas de Vercel, análisis, funciones en el borde y el ecosistema más amplio de plugins de Next.js, quedarse donde están mantiene su conjunto de herramientas y su historia de contratación simples. Cambiar a Vike solo para reconstruir lo que Next.js les ofrece de manera predeterminada carece de sentido.

En última instancia, la decisión depende de tres variables: experiencia del equipo, horizonte del proyecto y apetito por la propiedad. Los equipos compuestos mayoritariamente por personal senior que construyen sistemas duraderos y críticos para el rendimiento pueden justificar la fricción inicial de Vike. Los equipos más pequeños, los sitios de contenido y los MVP desechables todavía obtienen más ventaja de Next.js.

Los marcos modulares como Vike no son un camino peculiar; son el siguiente paso lógico después de una década de herramientas monolíticas de React. A medida que las aplicaciones han crecido, el modelo de "un marco para dominarlos a todos" ha comenzado a agrietarse bajo el peso de la complejidad del mundo real, los presupuestos de rendimiento y las bases de código de larga duración.

El auge de Vike, Astro y TanStack señala una demanda clara: los desarrolladores quieren primitivas composables, no religiones empaquetadas. Estas herramientas comparten una inclinación hacia núcleos pequeños, características opcionales y cableado explícito en lugar de carpetas mágicas y convenciones globales.

Astro popularizó la idea de islas y páginas con cero-JS por defecto. TanStack Start se basa en el control de la capa de datos y primitivas de enrutamiento en lugar de un runtime de todo en uno. Vike lleva esto más allá al permitir que React, Vue y Solid coexistan en una sola aplicación, en una sola página, sin adaptadores ni trucos.

Esa modularidad desbloquea beneficios prácticos. Puedes migrar una sección heredada de React a Vue de manera incremental, experimentar con Solid en una única isla, o ejecutar frontends multi-inquilino que personalizan las pilas por cliente sin necesidad de reescribir la plataforma.

El control no significa retroceder en capacidades. Vike aún te ofrece SSR moderno, SSG y despliegue en el edge a través de Photon, además de paquetes para clientes que a menudo rondan entre 10 y 15 kB en lugar de los 70 a 100 kB que ves en muchas construcciones de Next.js. Tú decides por página si será SSR, SSG o completamente del lado del cliente.

La estabilidad es parte de la propuesta. El "aburrido" núcleo con licencia MIT de Vike no persigue los Componentes de Servidor de React cada seis meses, lo cual es importante si planeas mantener un producto vivo durante cinco o diez años en lugar de un ciclo de financiamiento.

Si Next.js parece estar luchando contigo, sigue el consejo del video: crea un proyecto paralelo con Vike. Conecta un par de páginas, despliega con Photon, mezcla una isla o dos y descubre si un futuro modular realmente se siente mejor en tus manos.

¿Qué es Vike y en qué se diferencia de Next.js?

Vike es un meta-framework modular basado en Vite que proporciona capacidades fundamentales de SSR/SSG sin la estructura integral y opinativa de Next.js. Prioriza la flexibilidad, el control y el rendimiento, permitiendo a los desarrolladores elegir sus propias herramientas y arquitectura.

¿Puedo usar React, Vue y Solid en el mismo proyecto de Vike?

Sí. Una de las características principales de Vike es su capa de interfaz de usuario independiente del marco. Puedes usar React, Vue, Solid y otros frameworks juntos en la misma aplicación, incluso en la misma página, utilizando una arquitectura de 'islas' sin necesidad de envoltorios especiales.

¿Está Vike listo para la producción en 2025?

Vike se considera estable y es utilizado en producción por varias empresas. Sin embargo, su ecosistema es más pequeño que el de Next.js, lo que significa que necesitarás ensamblar más componentes como autenticación y optimización de imágenes por ti mismo. Es más adecuado para equipos experimentados que valoran el control y la estabilidad a largo plazo.

¿Cuáles son las principales desventajas de usar Vike?

Los principales inconvenientes incluyen un ecosistema más pequeño, menos funciones integradas (no es 'listo para usar') y una curva de aprendizaje inicial más pronunciada, ya que debes configurar la obtención de datos y otra lógica por ti mismo. La documentación también puede ser menos completa que la de Next.js para casos de uso avanzados.