Por que un sitio estatico

Este sitio es estatico. Sin base de datos, sin PHP, sin CMS que te pida actualizar diecisiete plugins antes de poder escribir una coma. Archivos HTML, algo de CSS, y ya. Y voy a explicar por que es exactamente lo que hace falta.

La fabrica que nadie pidio

WordPress. Ah, WordPress. La navaja suiza de la web, dicen sus fans. Salvo que una navaja suiza, en la practica, es un mal cuchillo, un mal destornillador y un sacacorchos aceptable. WordPress mueve el 40 % de la web, y aproximadamente el 40 % de la web es lento, vulnerable y esta lleno de popups de « Aceptar cookies ». Casualidad? (ejem)

Para un blog personal (unas cuantas entradas, unas cuantas imagenes, cero comentarios porque seamos honestos nadie comenta), WordPress es como coger un camion para ir a comprar el pan. Con aire acondicionado, GPS y copiloto.

Y las plataformas alojadas? Medium, Substack, todo eso? Resuelven el problema del mantenimiento, si. Pero a cambio, tu contenido vive en terreno ajeno. Sujeto a sus condiciones, sus pivotes estrategicos (porque hay que cerrar otra ronda de inversion), y su eventual cierre. No eres propietario. Eres inquilino. Y el contrato es rescindible sin previo aviso.

JavaScript, no gracias

Tenemos que hablar de JavaScript.

Mi relacion con JavaScript se podria describir como « conflictiva ». En el sentido de que JavaScript me produce urticaria y yo se la devuelvo. Un sitio web en 2026 carga de media 2 MB de JS antes de mostrar un solo parrafo. Dos megabytes. Para texto. Mandamos gente a la Luna con menos memoria de la que hace falta para cargar un articulo de blog en un framework React.

Mientras tanto, tu viejo portatil se ahoga, tu lector de pantalla se asfixia, tu tarifa de datos se derrite como nieve al sol, y la mitad del planeta con una conexion un poco lenta se queda mirando un spinner eterno. Todo para mostrar palabras. Palabras!

Quiero una web accesible. Que funcione en un telefono de 80 euros igual que en un MacBook Pro. Que se pueda leer con un lector de pantalla sin que el usuario quiera lanzar su ordenador por la ventana. Que cargue en un segundo con un ADSL rural. Que no le pida al navegador compilar un framework entero para mostrar un parrafo.

HTML semantico, CSS razonable, y casi cero JavaScript. Este sitio cuenta sus <script> con los dedos de una mano, y de una mano de Simpson, ademas. Mientras escribo esto, solo uno, en una sola pagina, para un esquema interactivo, porque a veces no queda otra. Todo lo demas es HTML puro. Intentad inspeccionar el codigo fuente si no me creeis. Es la pagina mas aburrida que vereis en todo el dia, y estoy orgulloso de ello.

De Pelican a Zola, pasando por Nikola

Un sitio estatico necesita un generador. Y ahi hay que elegir herramienta. He dado unas cuantas vueltas.

Pelican primero. Python, comunidad simpatica, cumplia con el trabajo. Hasta el dia en que quise algo un poco personalizado en las plantillas y acabe depurando Jinja2 a las 11 de la noche, preguntandome que habia hecho para merecer esto. El ecosistema de temas es... digamos vintage. Y la gestion multilingue era mas acrobacia que funcionalidad.

Nikola despues. Python tambien, mas completo, mas funcionalidades. Demasiadas funcionalidades, de hecho. Nikola hace blogs, sitios, galerias de fotos, Jupyter Notebooks, microformatos y probablemente cafe si se lo pides con educacion. Para mi necesidad (archivos Markdown, tres idiomas, HTML limpio de salida), era el camion, otra vez.

Y entonces Zola. Un solo binario. Sin dependencias. Sin pip install que rompe todo, sin virtualenv, sin Node.js (escalofrios). Se descarga, se ejecuta, funciona. El motor de plantillas esta integrado, el multilingue es nativo, la compilacion es instantanea (gracias, Rust). Es rapido, es sobrio, es exactamente lo que hace falta y nada mas.

La belleza de lo que no hace nada

Un generador de sitios estaticos toma archivos Markdown y produce HTML. Punto. Ningun servidor interpretando nada. Ninguna base de datos sentada pacientemente esperando a que un script kiddie venga a hacerle cosquillas.

Lo que eso significa en la practica:

• Es rapido. La pagina ya esta construida. El servidor no tiene literalmente nada que hacer salvo servirla. Hasta una Raspberry Pi de 35 euros aguantaria la carga.
• Es seguro. Sin codigo del lado del servidor = nada que explotar. Sin fallos PHP, sin inyeccion SQL, sin plugin dudoso instalado a las 2 de la manana y nunca actualizado desde entonces. La superficie de ataque es... HTML. Buena suerte.
• Es simple. El contenido es una carpeta de archivos de texto. Se meten en Git, se leen en cualquier editor, se copian en un USB si eres de los desconfiados (y haces bien).
• Es duradero. El HTML funciona desde 1991. La web sobrevivio a Flash, a los Java Applets, a Internet Explorer 6 y a los contadores de visitas animados. El HTML sigue aqui. Tu WordPress 5.3, dentro de diez anos, ya hablaremos.
• Es gratis (o casi). GitHub Pages, Cloudflare Pages, Netlify: se pelean por alojar tus archivos HTML sin cobrarte un centimo. Intenta hacer lo mismo con un WordPress autoalojado.

Escribir, no administrar

Escribir una entrada en este sitio es: abrir un archivo de texto, teclear, guardar. Sin panel de control. Sin formulario. Sin necesidad de conexion a internet para redactar (el wifi del tren, hablamos?). El contenido esta en Markdown, un formato legible a simple vista y convertible a cualquier cosa.

Y si Zola desaparece manana? (Es software libre, no estoy realmente preocupado, pero juguemos.) Los archivos Markdown siguen ahi. Cambio de generador en una tarde. Hugo, Eleventy, un script Bash casero un domingo de lluvia… al contenido le da igual.

Intentad migrar un WordPress de diez anos a otra cosa. No, en serio, intentadlo. Os espero. (sonidos de cafe que se sirve de nuevo)

La herramienta correcta, el uso correcto

Seamos honestos: un sitio estatico no lo hace todo. Si necesitas cuentas de usuario, comentarios en tiempo real, un carrito de compra o una aplicacion web, necesitas algo dinamico, y es normal. No estoy diciendo que toda la tecnologia moderna sea inutil (solo una buena parte, pero eso es otra entrada).

Pero para un blog? Un portfolio? Documentacion? Un sitio personal donde cuentas tu vida, tus juegos y tus opiniones mas o menos fundamentadas? Lo estatico es mas rapido, mas seguro, mas simple y mas duradero que todo lo demas.

Menos tecnologia, mas contenido. Y el contenido es lo que queda cuando los frameworks han desaparecido.

Los tres monumentos

Descubri estos sitios mas o menos al mismo tiempo que CrunchBang Linux. Para quienes no lo conocieron: CrunchBang (#!) era una Debian con Openbox, un fondo de pantalla gris, un menu al clic derecho, y nada mas. Arrancaba en tres segundos en un PC de 2005 y hacia todo lo que le pedias sin rechistar. El dia que instale #! en un viejo portatil que creia destinado al punto limpio, y esa cosa resucito como si nada… entendi que me habian mentido durante anos sobre lo que un ordenador « necesitaba » para funcionar.

Fue exactamente por esa epoca cuando me tope con estos tres sitios (almas sensibles al vocabulario florido, quedais avisados):

motherfuckingwebsite.com, el manifiesto original. Una pagina HTML en crudo, sin CSS, sin JS, sin imagenes, sin nada. Texto negro sobre fondo blanco. Y un argumento implacable: tu sitio es responsive? El mio tambien, por defecto, porque no hice nada para romperlo. Carga rapido? Obviamente, no hay nada que cargar. Es la bofetada que merece cada desarrollador front-end que alguna vez escribio npm install para mostrar texto.

bettermotherfuckingwebsite.com, la respuesta. Misma filosofia, pero con un poquito de CSS: un ancho maximo, una fuente legible, margenes correctos. El mensaje: no hay que elegir entre « feo y funcional » y « bonito e inutilizable ». Unas pocas lineas de CSS bastan. Ni un framework, ni un preprocesador, ni un bundler, solo CSS escrito por un ser humano que recuerda para que sirve.

thebestmotherfucking.website, el tercer acto. Un escalon mas en diseno (tema oscuro, tipografia cuidada), sin JS, ligero, accesible. La prueba de que minimalismo y estetica no son incompatibles. Se pueden hacer cosas bonitas sin hacerlas pesadas.

Estos tres sitios me ensenaron exactamente la misma leccion que CrunchBang me habia ensenado en el escritorio: la mayor parte de lo que apilamos en nuestras maquinas y paginas web no esta ahi para el usuario. Esta para el desarrollador, el disenador, el jefe de proyecto, la demo para el cliente. El usuario solo quiere leer un texto. Y para leer un texto, no necesita nada de todo eso.