¿Por qué ya no quiero usar un generador de sitios estáticos para mi blog?

Durante casi 8 años he usado un generador de sitios estáticos para mi blog pero ahora voy a mirar a un sitio dinámico. ¿Por qué? ¿Qué problemas he sufrido durante estos años que me han llevado a tomar esta decisión? Las causas son varias, tanto técnicas como de experiencia de usuario.

Primero os pongo en el contexto que estoy creando mi nueva web y era un tema que llevaba tiempo dándole vueltas. Desde mi punto de vista, las ventajas de un sitio estático no supera a sus inconvenientes. Sobretodo cuando llegas a ciertas características que todo blog debería implementar.

Ahora hablemos de los motivos por los que todos acabamos usando un sitio estático en un inicio. Lo que nos seduce:

• Mínimo mantenimiento: No hay que preocuparse de actualizaciones de software, sistemas operativos, ni de nada que involucre al blog. Puedes actualizar el script que genera el sitio, pero no es necesario para que tu sitio siga funcionando correctamente.
• Despliegue sencillo: Solo tienes que subir los archivos generados a un servidor web y ya esta. Sin pipelines complejos.
• Escribir con tu editor favorito: En mi caso me centré en Markdown, un formato sencillo y capaz de convivir con HTML. Por otro lado es fácil encontrar una extensión para resaltar la sintaxis en prácticamente cualquier editor de texto.
• Buen rendimiento: Al ser un sitio estático, toda la información que se sirve ya se encuentra preprocesada, por lo que el servidor web solo tiene que servir. Esto hace que el rendimiento sea muy bueno, incluso en servidores de pocos recursos. Para lograr resultados similares en un sitio dinámico, es necesario usar un sistema de caché, que añade inevitablemente complejidad al sistema.

Pero no todo son ventajas, hay que realizar ciertos sacrificios. Muchos de ellos se pueden solucionar con un poco de ingenio. En mi caso tape los agujeros con JavaScript y algunas APIs propias.

Entre las limitaciones más importantes que he sufrido durante estos años están:

• No hay posibilidad de programar una publicación: En otras palabras, no puedo escribir un artículo para que se visualice a partir de cierta fecha u hora. Lo más óptimo, tanto a nivel de SEO como de experiencia de usuario, es publicar en momentos concretos donde sabes que los lectores están más activos (como puede ser por la mañana, o después del trabajo) y en días de la semana que no sean festivos. Un sitio estático publicas cuando escribes, no hay más. ¿Puedes crear un script que cada día renderice el sitio y lo suba al servidor en momentos adecuados? Por supuesto. ¿Y donde ejecutas el cron? O en un servidor externo o tu equipo. Ya estamos añadiendo tecnología de páginas dinámicas.
• No puedo disponer de un formulario de contacto: Sin un backend, no es posible recoger la información y mucho menos enviarla por email. Lo resolví creando una pequeña API en Clojure cuya labor es justamente esa. Se denomina api2smtp y es simple de levantar. Pero no deja de ser un servidor que se ejecuta en segundo plano. Por supuesto que puedes usar servicios de terceros como Formspree, pero estas enviando información sensible a un tercero.
• No hay comentarios: Al no poder ejecutar código en el servidor, no es posible integrar un sistema de comentarios o un captcha. Se puede solucionar usando un servicio externo, como Disqus, o creando un sistema propio que interactué por medio de JavaScript. Yo tomé el camino largo: crear Glosa. Si no lo conoces, es un sistema de comentarios, también escrito en Clojure, con la capacidad de importar el contenido de Disqus, facilidad de integrar en cualquier sitio estático, envío de notificaciones por correo electrónico, multisitio, almacenamiento en JSON, con PWA para moderar los comentarios desde el smartphone, y otras características. En otras palabras, me hizo falta un servidor con código ejecutándose para poder tener comentarios.
• No hay integración con ActivityPub el RSS del nuevo siglo: Al igual que con los comentarios, no es posible integrar un sistema de federación. Un elemento importante para mi ya que quiero dar la posibilidad a que puedan seguir las novedades del blog desde cualquier cuenta de Mastodon, Pleroma, Pixelfed, PeerTube, etc. Incluso poder dar la posibilidad de comentar desde estos servicios.
• No hay buscador: Quien vaya visitado mi blog sabrá que ya tengo un buscador y sus resultados son instantáneos. ¿Entonces? Tuve que hacer un truco de magia negra. Cuando entras en la página descargas en caché una pequeña base de datos indexada que uso para realizar las búsquedas. No se nota, en tiempos de carga o ejecución, ya que no ocupa más que una imagen y el algoritmo de búsqueda es rápido, pero estoy llevando la carga a mi cliente.
• No hay panel administrativo: Pierdo la posibilidad de realizar un cambio muy rápido desde el navegador o smartphone: corregir alguna falta de ortografía, incluir nueva información, etc. Y no olvidemos de la capacidad para moderar los comentarios, internet esta llena de trolls. De ahí que tuviera que crear Glosa junto a una PWA. Y se añade la barrera digital. No puedo colaborar con otros colaboradores a no ser que posean cierto nivel técnico de Git y la sintaxis de Markdown.
• Falta de inmediatez en los cambios: Cuando escribes, al menos con Jekyll, no puedes ver el resultado en tiempo real. Debes esperar a que el servidor detecte los cambios y los compile en una previa. La situación se repite cuando despliegas los cambios en el servidor web. Su propia naturaleza hace que sea un proceso lento.
• No existe una experiencia personalizada: El visitante al no poder registrarse, no puede modificar el comportamiento de la página, ni recibir avisos, ni guardar información de forma permanente. Por ejemplo, en mi web se van marcando las lección vistas de los tutoriales que has leído. Los datos se almacenan en el navegador, mediante una Cookie, haciendo que sea imposible sincronizar la información a otro dispositivo. Por otro lado sigo abusando de JavaScript.
• El sistema de caché puede ser un problema: El servidor web no sabe cuando subiste cambios, por lo tanto no puede actualizar la caché ni averiguar cuando debe expirar cada archivo. Si no lo tienes en cuenta los cambios se demorarán en aparecer. Y si lo reduces demasiado, perderás cierto rendimiento de la web. Un sitio dinámico no tiene el problema mencionado ya que puede crear nuevas rutas dinámicamente y por lo tanto anular dicha caché.
• Gestionar manualmente el contenido multimedia: En un sitio dinámico puedes subir una imagen y el sistema se encarga de crear las miniaturas, optimizar el tamaño, convertir entre formatos, limpiar metadatos, etc. Incluso puedes implementar un sistema inteligente de redimensionamiento, que se adapte a la resolución de la pantalla, y que solo descargue la imagen en la resolución que se va a mostrar. En un sitio estático debes hacerlo todo tu mismo. O creando scripts que hagan una labor similar (tengo un gran script en Bash que ejecuto antes de desplegar). También puedes pagar por un servicio externo.

Todos los problemas de la lista se solucionan rápidamente con un sitio dinámico. Por otro lado puedo incluir más características como: multidioma, redirecciones dinámicas, formularios, avisos de publicación en redes sociales, y un largo etcétera.

¿Y que pasa con las 4 ventajas que mencioné al principio? ¿No se pierden? Para nada:

• Mínimo mantenimiento: Mantén a raya los plugins o extensiones externas. No instales nada que no necesites. Cada cierto tiempo revisa que no haya actualizaciones de seguridad. Y si las hay, actualiza. No es necesario que sea inmediato, aunque si con cierta frecuencia.
• Despliegue sencillo: Si usas un sistema de integración continua, como GitHub Actions, puedes automatizar el proceso de despliegue. Incluso puedes crear un sistema de despliegue continuo, donde cada vez que se suba un cambio a la rama principal, se despliegue automáticamente. Hoy en día con Docker es muy sencillo crear un entorno de desarrollo y producción idéntico.
• Escribir con tu editor favorito: ¿Por qué no? Puedes escribir en Markdown, HTML, o lo que quieras. Incluso puedes crear un sistema de previsualización en tiempo real. Continuo usando ficheros en texto plano en Markdown. Cada vez que mi web detecta un archivo modificado, actualiza la base de datos. No es complejo de implementar.
• Buen rendimiento: Si usas un buen sistema de caché en memoria, que no en disco, será más veloz que un sitio estático. Te recomiendo encarecidamente Redis o Memcached.

En conclusión, un sitio estático es una buena opción para un blog personal sin muchas pretensiones o que se despreocupa de la información de sus visitantes. Pero si quieres ir un paso más allá, o te profesionalizas, los sitios dinámicos rompen cualquier limitación incluso llegando a superar las ventajas de un sitio estático. Por supuesto, todo depende de tus necesidades y tus habilidades técnicas. No olvidemos que para la gran mayoría de los casos, un sitio estático es más que suficiente. Pero te dejo una última reflexión, ¿es suficiente para tus lectores?