Aventuras con SSGs

2026-08-09T00:00:00+00:00

Es ley que todo usuario de la IndieWeb tenga como primera publicación un texto explicando sus primeras desventuras creando y desplegando su página web personal.

Mi caso no es una excepción, originalmente intenté dar vida a mi página, primero creando mi propio SSG (Static Site Generator), del que aún quedan resquicios. Poco después me di cuenta de la complejidad que esta tarea tenía, y con la universidad aun consumiendo mucho de mi tiempo decidí dejar este proyecto aparcado un tiempo.

Quiero con este artículo hacer una prueba de contacto a la escritura y formato propios de un blog, y comentar el proceso creativo y de diseño que han llevado al stack de tecnologías actuales de dobon.dev.

Y al principio estaba lobste.rs

Mi interés por tener mi propio espacio digital viene de tiempo atrás. De forma accidental, buscando resolver las distintas dudas que me surgían en mi viaje autodidacta en el mundo de la informática, encontraba textos que me parecían de un gran interés y aprendizaje, pues en muchos casos me abrían las puertas a conceptos completamente nuevos.

Las explicaciones de Michael Stapelberg sobre su gestor de paquetes experimental d1stri, las detalladas explicaciones de Xe Iaso sobre su paranoica configuración de NixOS o el rant de Aria Desires sobre la situación actual de los ABIs basados en C eran pequeñas ventanas hacia todo aquello de mi gremio que no conocía.

Fue con ello natural que de mí surgiera el deseo de escribir y compartir mis opiniones y descubrimientos, que se mantuvo latente pero constante a lo largo de los años. Al llegar a la universidad y hablar con mis semejantes, me di cuenta de que quizá había infravalorado tanto mi capacidad de enseñar y mostrar a otros mis descubrimientos, como del placer que me es hacerlo.

Pasado el primer cuatrimestre, algo más asentado en la vida universitaria, tomé la decisión de dedicar mis escasos momentos libres a la construcción de mi propia página web. Durante ese periodo, en mi rutinaria lectura de lobste.rs, me encontré una nueva entrada, clara y directa: Why You Should Write Your Own Static Site Generator (entrada en lobste.rs).

Con ello, motivado por este artículo, abrí RustRover con la intención de crear un SSG que cumpliese una breve y humilde lista de características:

Renderizado incremental.
Renderizado basado en plantillas HTML.
Soporte multiidioma.
Generación de fuentes Atom.
Optimización de imágenes AVIF y generación de fallbacks WEBP y JPEG.
Recarga en caliente (Hot reloading).
Sistema de taxonomías.
Soporte de comentarios con Webmention.
Minificación de HTML, CSS y JS.
Sindicalización POSSE.

Espero que se haya hecho notar la ironía... Visto en retrospectiva mi error está claro, la complejidad del sistema que yo necesitaba era demasiado alta. El desarrollo fue rápidamente cuesta arriba por un segundo cuatrimestre que ya estaba funcionando a todo rendimiento y una serie de restricciones autoimpuestas, quería que fuese un SSG generalista en toda regla, y no un programa de planta de interior.

Todo esto llevo a que el proyecto acabara de forma prematura, insatisfecho con lo que había logrado hacer. Creo que hubo unos puntos clave que dificultaron mucho la tarea:

Menosprecie la dificultad de crear una caché funcional y la poca necesidad de renderizado incremental en la mayoría de SSGs, dada la velocidad de renderizado que pueden llegar a alcanzar.
La conversión entre formatos de imagen resulto ser más compleja que añadir una librería adicional y una llamada extra a una función, ImageMagick tiene una API de una complejidad elevada.

En pocas palabras:

Hay solo dos cosas difíciles en la informática: la invalidación de caché y nombrar cosas.

— Phil Karlton (Traducido, fuente)

Hugo me marea

Paso un tiempo de desconexión sobre este tema; un proyecto de autoalojado (self-hosting), sobre el que quiero escribir en un futuro, tomó gran parte de mi tiempo.

Recién entrando en el mes de agosto quise de una vez por todas tener una página propia, me decanté por Hugo, que es sin duda, junto a Jekyll, Eleventy y Astro, uno de los SSG más usados del mundo...

No fue una tarde productiva, la documentación de Hugo resulto ser un desastre. Más cercana a una referencia que a un documento que sirva para aprender a usar la herramienta, introduce constantemente conceptos nuevos y peca de enlazar demasiadas páginas entre sí, lo que vuelve todo algo agobiante.

Su guía Quick start trata a la herramienta como una caja negra, obligando la instalación de un tema, pues no es explicado en ella como funciona el sistema de plantillas y estilizado.

El glosario de Hugo

Esta sección originalmente no iba a estar escondida tras un desplegable, pero me extendí demasiado en ella. Además, me quedó demasiado como un rant.

Para ejemplo de esta problemática se encuentra su glosario de términos, que presenta multitud de problemas como:

La adición de términos comunes en la informática que solo llevan a que el glosario sea demasiado extenso, por ejemplo:
- Booleano: Un booleano es un tipo de dato con dos posibles valores, o verdadero > (true) o falso (false).
- Caché: Una caché es un componente de software que almacena datos para que > futuras peticiones de los mismos sean más rápidas.
- CLI: CLI significa Command Line Interface, un mecanismo basado en texto que > permite la interacción con programas informáticos o sistemas operativos.
— El glosario del SSG Hugo (Traducido, fuente)
La existencia de términos proxy, por ejemplo:
- Dimensión de un contenido: Vea dimensión.
- Bundle: Vea bundle de una página.
- bool: Vea booleano.
— El glosario del SSG Hugo (Traducido, fuente)
La invención de terminología innecesariamente compleja:

Dimensión: Una dimensión es un eje de variación de un contenido que permite que múltiples variaciones lógicas de una página existan simultáneamente. Las tres dimensiones son idioma, rol y versión.

Por ejemplo, una página lógica puede que exista en 6 idiomas, 4 versiones y 2 roles.

— El glosario del SSG Hugo (Traducido, fuente)

Que no se me malinterprete, este glosario no se trata de un problema crítico, pero sí ejemplifica a la perfección el mal estado de la documentación de Hugo.

¿Y si uso Bash?

Durante un muy breve periodo de tiempo se me ocurrió la idea no utilizar un SSG, sino una serie de scripts en Bash que dieran uso de herramientas como Pandoc o yq.

La idea duró una tarde. Vi en poco tiempo como iba a acabar con los mismos problemas que con mi intento original de SSG, además, recordé mi odio hacia el shell scripting.

Usando Zola

Finalmente, di una segunda oportunidad a una herramienta que en un pasado rindió sin peros y que todavía no sé por qué la deje a un lado, Zola.

No tengo ninguna queja, su Getting Started - Overview me guio rápidamente en la creación de un sencillo blog personal, mostrando en el proceso el funcionamiento de su sistema de plantillas y su breve terminología basada en páginas, secciones e índices.

Es un SSG que busca ser rápido, no entrometerse en tu diseño y tener las funcionalidades justas y necesarias.

Hablemos del Open Source

En una nota más personal, me alegró ver que el proyecto sufrió una transición de una licencia MIT (permisiva) a la EUPL (libre y vírica). Me gustaría incluir el siguiente fragmento de una conversación que ocurrió en GitHub:

Desafortunadamente, esto es un gran cambio para los usuarios corporativos de los EEUU. La EUPL está categóricamente prohibida en la industria tecnológica, pues es agrupada junto a la AGPL y la SSPL. Esta licencia hace a efectos practicos a Zola imposible de incluso ejecutar su binario en cualquier entorno comercial estadounidense. — psarossy

¿Una pena para los usuarios corporativos de los EEUU entonces? No hay razón ninguna para agrupar la EUPL con la AGPL. [La versión] 0.21 está todavía disponible para esos usuarios. — Keats (creador de Zola)

— Extracto de la conversación del Issue #3093 del repositorio de GitHub de Zola (Traducido, fuente).

Creo que ilustra a la perfección la asimétrica situación en la que nos encontramos en el mundo Open Source. El mundo corporativo y profesional ha creado unas expectativas sobre voluntarios y gente que ejerce de la informatica como hobby, obligandoles a proveer productos y un servicio de excelencia y business-ready.

Creo que es relevante enunciar una vez más una serie de verdades muchas veces olvidadas:

Toda persona es libre de crear cuando y como quiera, ignorando si lo creado presenta o no una utilidad práctica.
No tienes la obligación de examinar Pull Requests o cualquier otra propuesta de adición de código, sea escrita por humano o IA.
ESTE SOFTWARE SE PROPORCIONA "TAL CUAL", SIN GARANTÍA DE NINGÚN TIPO.

Recomiendo mucho el texto help wanted por Lake Hope, que explora en mayor profundidad este tema.

Post mortem

Por un lado, me alegra mucho tener por fín un sitio en el que compartir mis ideas y opiniones. Pero, no puedo evitar tener el pensamiento de que no he logrado tener la virtud propia de un ingeniero informático; el desgaste (o burnout), el cansancio y el desconocimiento han jugado un factor clave en esto, pero no haber sido capaz de desarrollar un programa SSG más competente me deja una sensación agridulce en el cuerpo.