Por qué importa static-only
Por qué Jenna Press eliminó las suposiciones de servidor y eligió un modelo de publicación puramente estático.
La entrega estática es una decisión estratégica, no un compromiso técnico
La mayoría de los proyectos CMS comienzan con un objetivo práctico: publicar contenido, dejar que la gente lo encuentre. En algún momento del primer año, el sitio crece silenciosamente una base de datos, una capa de runtime, un pipeline de despliegue y un conjunto de reglas de edición que nadie recuerda completamente. La intención original era publicar — el resultado real es una aplicación ligera que requiere mantenimiento continuo.
Esto no es un fracaso del equipo. Es una deriva estructural que ocurre porque la mayoría de los frameworks facilitan añadir comportamiento de runtime y dificultan notar el peso acumulado hasta que ya está ahí.
Qué cambia realmente cuando añades una capa de servidor
Un sitio dependiente del servidor hace dos cosas que parecen convenientes y causan problemas con el tiempo.
Primero, crea una dependencia operativa. El contenido vive en algún lugar que necesita estar funcionando, monitorizado y actualizado. Cuando esa capa cae, el sitio cae. Cuando necesita actualizarse, el sitio necesita una ventana de migración. El equipo ahora posee infraestructura, no solo publicación.
Segundo, crea una superficie de mantenimiento implícita. Una vez que existe un servidor, se vuelve natural añadir gestores de formularios, autenticación de usuarios, sistemas de comentarios y endpoints de API — uno a uno, sin un punto de decisión claro para cada uno. Cada adición reduce el equipo que puede trabajar en el sitio con confianza.
El cambio hacia canales sociales hace que la carga operativa sea peor
La estrategia tradicional de sitios web asumía que un formulario de contacto era un canal razonable de captura de leads. Alguien lee el sitio, llena un formulario, alguien hace seguimiento. Esa suposición ya no coincide con cómo llegan los clientes modernos.
Hoy, la función principal de un sitio web de proyecto no es convertir visitantes a través del propio sitio. Es ser encontrable, ser creíble, y transferir la relación a un canal de redes sociales — un perfil de LinkedIn, un repositorio de GitHub, un hilo de X — donde el compromiso real realmente ocurre.
Un sitio que carga lentamente, requiere mantenimiento de servidor, y dedica su presupuesto de contenido a formularios de „contáctenos" está optimizado para un flujo de trabajo que la gente ya no usa. Mientras tanto, el canal de redes sociales que realmente impulsa el interés recibe solo un enlace genérico en el pie de página.
Lo que static-only cambia
La entrega estática elimina la dependencia operativa por completo. El sitio son archivos en un CDN. No hay runtime que monitorizar, ningún servidor que parchar, ninguna base de datos que respaldar. El flujo de trabajo de publicación es: escribir markdown, ejecutar el build, desplegar. Esa es toda la superficie operativa.
Más importante aún, la restricción estática fuerza claridad sobre para qué sirve realmente el sitio. Cuando añadir una característica requiere preguntar si pertenece a un build estático o a un servicio separado, la decisión se vuelve explícita. Las características que no pueden funcionar de forma estática — un widget de chat en vivo, un feed en tiempo real — se descartan o se delegan a un servicio externo con una transferencia clara. El proyecto se mantiene ligero porque el framework no hace que la ligereza sea opcional.
Lo que static no resuelve
La entrega estática no es una respuesta universal. Un sitio que necesita contenido generado por usuarios, colaboración en tiempo real o lógica transaccional no puede ser static-only sin añadir servicios externos que reintroducen la complejidad que la restricción intentaba evitar.
Jenna Press no argumenta contra esos casos de uso. Argumenta por ser honesto acerca de ellos: si el proyecto no necesita una capa de servidor, no debería cargar con una solo porque el framework hizo que fuera fácil añadirla.
El límite estático en Jenna Press es una función de presión para esa honestidad. Mantiene el alcance del sitio web del proyecto visible y la atención del equipo en el contenido que hace que la gente entre, no en la infraestructura que los mantiene fuera.