La paradoja de los sitios estáticos
(kristoff.it)- Incluso en sitios simples como un blog personal o una página de contacto, los usuarios comunes suelen quedarse en CMS como WordPress, mientras que los sitios estáticos en HTML terminan siendo, irónicamente, más fáciles de operar para ingenieros profesionales
- Para crear un sitio estático por cuenta propia, hay que resolver varios pasos intermedios: comprar un dominio, elegir hosting, configurar DNS, escoger un SSG y armar un pipeline de despliegue
- Los ingenieros aprovechan hosting gratuito y dominio personalizado con GitHub Pages o Cloudflare Pages, pero los usuarios comunes terminan dependiendo de servicios más pesados y caros incluso cuando un sitio estático sería suficiente
- SuperHTML se presenta como el primer servidor de lenguaje para HTML que reporta diagnósticos al usuario; las herramientas de diagnóstico existentes suelen estar atadas a frameworks específicos de frontend, por lo que es difícil usarlas solo con HTML vanilla
- Si no logramos hacer más fácil el desarrollo web simple, la web se alejará de los no especialistas, y los usuarios comunes serán empujados hacia espacios cerrados como las redes sociales
La paradoja de que los sitios estáticos sean más difíciles
- Se contrastan dos ejemplos de sitios web personales
- Uno es un CMS complejo escrito en PHP y requiere un servidor web, varios workers, caché Redis y una base de datos SQL
- El frontend también se carga como una Single Page Application, solicita el contenido en formato JSON y luego lo reconstruye en el cliente
- El otro está compuesto por archivos HTML estáticos y uno o dos archivos CSS, sin JavaScript
- A simple vista parecería que los usuarios comunes usarían un sitio estático sencillo y los ingenieros profesionales una estructura compleja, pero en la práctica ocurre casi lo contrario
- Para que un usuario común opere un sitio estático por sí mismo, tiene que superar varias etapas
- Comprar un dominio
- Encontrar una plataforma de hosting
- Configurar DNS
- Elegir un SSG o crearlo por cuenta propia
- Armar un pipeline de despliegue
- En cambio, los ingenieros de software pueden aprovechar hosting gratuito y soporte para dominios personalizados mediante GitHub Pages, Cloudflare Pages y otros
- Como resultado, incluso en el 99% de los casos en que un sitio web estático sería suficiente, los usuarios comunes quedan atados a soluciones complejas que cuestan más y consumen más recursos de cómputo
La necesidad de herramientas que faciliten una web simple
- Una charla en SquiggleConf, en Boston, trató sobre la experiencia de implementar un servidor de lenguaje para HTML, y la conclusión lleva al problema de la accesibilidad de la web
- SuperHTML se presenta como el primer servidor de lenguaje para HTML que reporta diagnósticos al usuario, y el artículo relacionado llegó a la portada de Hacker News
- Existen linters y también diagnósticos en el editor, pero por lo general están atados a frameworks específicos de frontend
- Por eso los usuarios terminan eligiendo un framework aunque en realidad no necesiten esa complejidad
- La web no es solo para ingenieros de software, y cuanto más compleja la hacemos, más empujamos a los usuarios comunes dentro del cerco de las redes sociales
- Ni las startups ni las big tech pueden resolver fácilmente este problema por nosotros, porque los incentivos económicos no están alineados; hace falta facilitar más la web simple
1 comentarios
Comentarios en Hacker News
He tenido muchas experiencias amargas tratando de convencer a equipos de marketing de dejar WordPress y usar sitios estáticos
Al final, lo que importa es la facilidad de edición. Un sitio en WordPress está optimizado para el editor, no para el hosting, el personal técnico, contabilidad ni los lectores, y las personas que editan el sitio terminan decidiendo cómo se implementa
Si les haces elegir entre un sitio que renderiza en menos de 100 ms, es completamente seguro y cuesta 0 en hosting, pero requiere archivos Markdown y un poco de despliegue con Git, y WordPress, que es lento, caro, vulnerable y necesita mantenimiento constante, pero ofrece una buena experiencia de edición, siempre eligen WordPress
Siempre me ha confundido por qué estas personas tienen poder de decisión, pero aunque repitas el mismo experimento muchas veces, el resultado siempre es el mismo
No entiendo por qué sería raro elegir WordPress en lugar de aprender a usar un editor de texto y Git. El experimento debería comparar WordPress con una herramienta que ofrezca una buena experiencia de edición pero que por detrás genere un sitio estático y lo despliegue con Git. Ahí sí los requisitos secundarios, como seguridad y velocidad, podrían volverse relevantes
Más que un blog, se parece a una aplicación personalizable que una persona no técnica puede armar a golpes para que haga lo que quiere, solo con clics y arrastrar y soltar. Ni siquiera hace falta programar hasta que te hackean o aparece una necesidad realmente personalizada que requiere a un ingeniero de verdad
Si usas Hugo, Ghost y otros, terminas llegando a “esto necesita otra plataforma”, y esa plataforma pasa a ser Shopify, un sistema contable, un plugin de red social/membresía, una bolsa de trabajo, etc. WordPress se convirtió en una cosa que puede transformarse en cualquier cosa
Si alguien le dice a un consultor lo que quiere, la respuesta es “te lo configuro en WordPress”, y como todo el mundo usaba WordPress, era fácil encontrar a alguien que resolviera problemas, ajustara un poco un plugin o conectara un hook de envío de correos. La era de los consultores PHP construyó el dominio de WordPress
El problema es que la mayoría, incluso las soluciones de pago, no son soluciones completas. En cuanto empiezas a usarlas, te das cuenta rápido de que WordPress impone restricciones absurdas. Ni siquiera puedes diseñar una tienda online fuera del desastre de rendimiento de un sistema de entidades/metadatos que tarda 5 segundos en consultas de tamaño moderado y genera 50 consultas secundarias no optimizadas. Algunos plugins incluso evitan WordPress y crean sus propias tablas en la base de datos
Fuera de los blogs, WordPress tiene una arquitectura pésima, pero se usa como herramienta para todo. Otros CMS no hacen eso, por eso la gente no los usa
El contenido igual puede distribuirse como archivos estáticos generados a través de un CDN. Un sitio estático no tiene por qué requerir Markdown y Git
Llevo mucho tiempo buscando una cadena de herramientas en la que incluso un becario sin ninguna experiencia técnica pueda publicar cambios sin quedar atrapado en detalles técnicos, pero todavía no la encuentro
Lo más cercano es poner un generador de sitios estáticos encima de un CMS headless, pero, siendo honesto, todos me parecen bastante malos
En 2016, cuando trabajaba en una agencia que hacía sitios de presentación para negocios locales, un cliente pidió que le agregáramos un pequeño
iframepara un sistema de reservas en el sitio que habían hecho. Lo único que enviaron fue un documento de Word y resultó que lo exportaban a HTML y lo subían a un hosting compartido baratoLes funcionaba de maravilla. Podían mantener siempre actualizado el menú en línea porque solo tenían que exportar el mismo documento de Word con el que hacían el menú impreso. En ese momento internamente nos burlamos un poco, pero ahora me siento mal al pensarlo. Cuando tienes un millón de cosas más importantes que hacer, como operar un restaurante, en realidad es una forma genial de hacerlo
Hacer un sitio estático sigue siendo más fácil. El problema es que hoy las herramientas de autoría que generan HTML no son muy buenas o, incluso si lo son, traen encima algún proceso que tiene que correr en un servidor para poder servir el sitio
Mi trabajo no es burlarme diciendo “podría hacerse mejor”, sino mejorar su solución y hacer que la solución que yo les doy funcione al menos igual de bien, o mejor si es posible, sin estorbar el éxito que ya habían conseguido
A muchos desarrolladores no les gusta admitirlo, pero este tipo de soluciones web improvisadas muchas veces funciona mejor que varias estrategias que un desarrollador web experimentado implementaría por su cuenta
Lo importante es qué ofrece el negocio y cómo se relaciona e interactúa con sus clientes. A veces, exportar un documento de Word a HTML es suficiente. La tecnología puede mejorar eso, pero la verdadera magia está en la gente que opera el negocio
A veces encontrar una manera de mejorar estas soluciones de verdad es bastante difícil. Puedes hacer un sitio mejor y desplegarlo en una infraestructura sofisticada, pero al final, ¿al cliente le gusta más? ¿el negocio mejora? Esa parte puede no ser nada trivial
Llevo años buscando una buena alternativa que genere HTML más correcto que la exportación HTML de Word y que además dé más opciones
Me encanta eso. También hay muchos sitios de un solo archivo HTML hechos con Vue template, sitios publicados como documentos públicos de Notion o bibliotecas de fotos en línea de iCloud. Sorprende lo fácil y ampliamente posible que se ha vuelto simplemente conectar cosas, y también te hace sentir cuántas veces complicamos el trabajo cuando intentamos construirlo todo desde cero
Cuando no hay tiempo, también me gustan cosas como mmm.page para armar rápido micrositios pequeños o sitios de una sola ocasión. Es divertido explorar estas herramientas
Pero algunos “documentos” de ciertas páginas eran simplemente conjuntos de tablas con fechas y texto, administrados directamente por el cliente. La solución a la que llegamos terminó siendo parecida. Ponían las tablas en un documento de Word, nos lo enviaban y nosotros lo exportábamos a HTML/CSS para insertarlo en el lugar adecuado
No es una solución elegante ni escalable, pero para ese caso de uso concreto es por mucho la forma más fácil
Fue asombroso entonces y sigue siéndolo ahora. En silencio, hicimos realidad el sueño de llevar la computación a todo el mundo
En este momento estamos viviendo este problema con fuerza en Asheville. Incluso cuando apenas regresó el servicio celular, todos seguían con un 3G terrible que se cortaba todo el tiempo, y ninguno de los sitios web donde había que conseguir información básica de supervivencia cargaba
Gente buena hizo sitios de noticias de solo texto, y hoy vi que el sitio web del condado de Buncombe también tenía una versión de bajo ancho de banda, pero al abrirla seguía bloqueada por 130 KB de Bootstrap CSS y 50 KB de jQuery antes de renderizar
Es excelente que la gente haga estas cosas, pero los ciudadanos las necesitaban hace semana y media. A estas alturas ya averiguaron dónde conseguir agua, comida, agua no potable, etc. Pasar por esto y ver a la tecnología fallar tan duramente me abrió los ojos de una manera deprimente
El mapa de apagones de la compañía eléctrica está escondido detrás de un inicio de sesión, y se renderiza con clustering elegante y funciones de UI que ya son lentas incluso con una conexión decente. Así que revisar el estado o reportar un apagón toma bastante tiempo
También se puede llamar a la compañía eléctrica, pero configuraron el menú con navegación por voz en vez de tonos del teclado, y no reconoce bien la voz distorsionada por una conexión mala de 4G o 2G
Se necesitan longitudes de onda largas y baja potencia. Pero la accesibilidad es demasiado baja y no estoy seguro de que sea por una buena razón
Desde Black Mountain hasta la frontera entre Tennessee y Georgia, todo quedó desconectado. Dudo que mucha gente vuelva a tener señal, aunque sea ese pésimo 3G. Lo que sí sé es que fue difícil mantener el contacto con la gente que vive allá
Parte de mi mejor trabajo lo hice en una MacBook de 12 pulgadas conectada a un Wi‑Fi inestable de hotel. Por eso me importa muchísimo la velocidad de página
Si tuviera que resumir el dolor de este desastre en una sola frase, sería el colapso de la comunicación en todas sus formas
Estoy muy de acuerdo con la frase: “La web no les pertenece solo a los ingenieros de software. Cuanto más compleja la hacemos, más empujamos a los usuarios comunes dentro del cercado que llamamos redes sociales”.
También hay un pódcast sobre la conferencia reciente Squiggle Conf, de donde salió esta cita: https://changelog.com/jsparty/339
Con el paso del tiempo, las expectativas de la gente sobre lo que debe hacer un “sitio web básico” han subido muchísimo.
Incluso yo, siendo programador, he caído varias veces en la trampa de los generadores de sitios estáticos.
Empiezo un proyecto paralelo con un generador de sitios estáticos y, en cuanto quiero agregar una función pequeña, me irrita darme cuenta de que habría sido mejor empezar simplemente con una app sencilla en Rails o PHP.
Hoy en día, si necesito un sitio estático, simplemente empiezo con una carpeta de archivos HTML. Sin debates eternos sobre herramientas ni postergaciones, el camino de la idea a la ejecución es mucho menos complicado y más rápido.
A mí me gusta bastante escribir HTML y CSS directamente, pero no se lo recomendaría a todo el mundo.
Otra cosa genial es que, si después decido “escapar” a Rails, basta con copiar la carpeta de archivos HTML dentro de la carpeta
public/de Rails. La ruta de actualización es bastante fácil.En el mundo Ruby, el más conocido es Jekyll, pero está pensado para un caso de uso específico: escribir blogs en Markdown u otros lenguajes ligeros de marcado. Se puede forzar para otros usos, pero como generador estático de propósito general no resulta tan cómodo.
Si quieres algo fácil de copiar y pegar en Rails, middleman, que es un generador de sitios estáticos basado en Rack, está bien. Puedes escribir desde el inicio con erb/haml y ActiveSupport.
Si quieres mantener la simplicidad de escribir HTML y CSS a mano, pero solo con comodidades como include, plantillas parciales y helpers de enlaces, nanoc funciona bien como generador de sitios estáticos gradual. Puedes empezar con HTML/CSS normal e ir agregando funciones solo cuando las necesites.
De vez en cuando escribo algo de código para personalizar su comportamiento, pero es como una vez cada varios años. Es simple y simplemente funciona.
Hay cosas que extraño de los sitios dinámicos, pero no veo muy claro en qué sentido una simple carpeta de archivos HTML sería mejor que Pelican.
La regla fundamental que establecí para evitar que el sitio se inflara de funciones fue definir qué identidad quería que tuviera. Quería que fuera un archivo de las cosas que he hecho, y un archivo debería durar muchísimo tiempo. Por eso los archivos estáticos, fáciles de copiar, reflejar y ejecutar en cualquier plataforma de hosting, son lo correcto.
Me tomó algo de tiempo resolver bien el tema de un sitio multilingüe, pero al menos fue un costo que pagué una sola vez.
Los cambios de estilo también pueden volverse un problema si están hardcodeados en archivos HTML.
Para trabajos más avanzados uso Django. Agregar funciones ahí me resulta muy fácil.
.md→.htmlpara el contenido, pero hasta ahora no me ha hecho falta.También está bueno poder ver el sitio fácilmente con un servidor local. Lo ideal sería que también pudiera verse con
file://, pero como no logré desenredar por completo la estructura, terminé con un pasomake localque genera una copia aparte para visualización basada en archivos.Hay un factor que empuja a complicar los sitios personales de los desarrolladores web: el desarrollo guiado por el currículum.
Hay profesionales que quieren usar sus proyectos personales paralelos para desarrollo guiado por el currículum, y creen que así es menos probable que arruinen los proyectos del empleador.
Por ejemplo, hoy por la mañana tenía un sitio independiente que iba a publicar pronto, construido principalmente con un framework web moderno y popular por razones de currículum, y ya no puedo actualizar el sitio.
Un paquete de NPM tenía un problema de seguridad crítico, y cuando intenté actualizarlo, NPM quedó atrapado en un conflicto de dependencias mutuas que no podía resolver automáticamente. Irónicamente, por eso no pude subir una actualización de seguridad al sitio en producción.
Ese sitio podría haber sido solo 5 archivos HTML escritos a mano, un poco de JS inline y 2 pequeños scripts CGI en Perl. Entonces habría funcionado perfectamente incluso dentro de 25 años.
En cambio, solo la parte de NodeJS ya tiene 129 paquetes de NPM, actualizaciones de seguridad frecuentes, fragmentos de plantillas, configuración de TS y un árbol enrevesado de archivos fuente hechos de handlers.
Pero los profesionales no pueden darse el lujo de no hacerlo de una manera absurdamente compleja. Por ejemplo, tener Perl en el currículum es prácticamente mortal para las posibilidades de empleo. Incluso quienes no tiraron su currículum por discriminación por edad pensarían que eres tonto si no hiciste desarrollo guiado por el currículum.
En mi caso no me interesa en absoluto el currículum ni las propuestas, pero aun así quiero algo más ergonómico que escupir HTML desde plantillas de JS/Python. Por eso mis sitios usan una combinación de TypeScript, Mithril, Express y algunas librerías utilitarias.
No sé cuántos paquetes hay ni me importa. Mientras lo que traiga sea maduro y no produzca una nueva combinación de función-vulnerabilidad cada pocos minutos, me basta.
No mencionaste el stack, pero parece muy probable que sea React y su ecosistema de “siempre mejorando pero nunca terminando”. Si me permites un consejo no pedido, conviene no creer en el falso dilema. Hay muchísimo espacio entre HTML puro y el peor lodazal, y la situación del mundo React es específica de React, no representa necesariamente lo que hay fuera de él.
La aplicación matadora de WordPress son los comentarios. Los generadores de sitios estáticos, casi por definición, no permiten comentarios, pero los blogs de WordPress casi siempre los traen integrados
Si algo como Hugo realmente quiere despegar en el espacio de los blogs, solo tendría que hacer temas bonitos con comentarios. Solo hay que resolverlo a escala. Por ejemplo, se podría usar SQLite particionado por blog para que terceros puedan alojarlo muy barato. Entonces se volvería una pequeña gallina de los huevos de oro
Los comentarios y la discusión sobre los artículos están en comunidades de terceros como Reddit, HN y Facebook. ¿Qué crees que tiene más lectores: la gente que hojea la lista de comentarios debajo de una publicación de Substack, o la que lee una o dos páginas de comentarios en HN sobre ese mismo texto?
Si es un artículo técnico, casi está garantizado que la discusión en HN tendrá más calidad que la cadena de comentarios del propio artículo. HN ya atrajo una audiencia más amplia que el 99.9% de todos los blogs
La principal ventaja de comentar directamente en una entrada del blog es solo que es mucho más probable que el autor lo vea. Estar un rato en la portada de HN es algo efímero
El ecosistema de WordPress es lo opuesto. Hay negocios de miles de millones de dólares formados alrededor de entender profundamente qué necesitan las personas que operan CMS y sitios web en sus pequeños nichos de mercado, y el tamaño de ese mercado es de aproximadamente 500 millones de sitios web
La persona que escribió esto seguramente es inteligente, pero claramente no lo es en cuanto a los usos prácticos de un CMS. La visión de mundo de que “los sitios estáticos en HTML son mejores, pero no son populares por culpa de empresas malvadas” casi siempre se desmorona cuando haces uno o dos sitios web cobrando por ello
Es muy poco probable que un generador de sitios estáticos en HTML haga todo lo que quiere un cliente. WordPress entendió hace mucho qué tan amplio y diverso es este mercado, y por eso implementó soporte para plugins
Estoy 100% de acuerdo en que los comentarios fueron uno de los usos originales para usar en la web algo más cercano a un CMS en vez de un generador de sitios estáticos. Pero además hay un millón de usos más
Solo con documentos HTML estáticos no llegas muy lejos. En cuanto sales del blog minimalista para desarrolladores, necesitas bastante lógica de programa para hacer lo que quieren usuarios y clientes reales. Por eso usas un CMS adecuado a tus necesidades, y si necesitas aguantar mucho tráfico, lo cacheas agresivamente. Eso también es parte del trabajo
De verdad no entiendo por qué los desarrolladores que se creen tan geniales quieren reinventar la rueda en vez de aprender un poco cómo funciona el caché y aplicarlo. ¿Será porque esto también es un “problema resuelto” demasiado aburrido?
Yo también uso Hugo, pero aunque desde el punto de vista de ingeniería su huella sea innecesariamente grande, la experiencia de usuario de WordPress es mucho más amable
No todos los sitios de negocio quieren comentarios, pero probablemente sí quieran un formulario de contacto. Publicar una dirección de correo también es una alternativa, pero es mejor manejar una canalización de entrada
En un sitio estático tienes que encontrar un servicio confiable que procese los envíos y conectarlo bien al sitio. Es una pieza móvil más, puede convertirse en otra factura aparte, y es otro elemento más que hay que gestionar cuando la industria se consolida
https://hn.algolia.com/?q=%22disqus%22
Facebook también ofrecía un sistema de comentarios que muchos sitios usaban, pero perdió confianza y alcance por varios escándalos
Yo también encajo en esa paradoja. Reescribí mi sitio web personal en PHP moderno, sin framework ni base de datos
En su mayor parte es un sitio estático, pero uso PHP para agregar el encabezado y procesar listas como la de entradas del blog. Me resultó un poco más cómodo que fuera no completamente estático. Escribo una entrada, hago commit, push, y de inmediato queda en línea. La mayoría de los generadores de sitios estáticos me parecieron demasiado complejos
El código de una sola página es más o menos algo como
title = "Blog Article Title";,$this->shortTitle = "Title";,$this->date = mktime(0,0,0,1,27,2024);,if ($this->mode == PageMode::Meta) return;, seguido del contenido HTML en brutoEl router agrega automáticamente el encabezado y el pie del sitio, y si añades un archivo
_layout.phpa una carpeta, puedes agregar un nivel más de layout a las páginas hijas. La página de listado del blog recorre los archivos individuales de artículos dentro de la carpeta y construye el índiceAhí es donde se usa
$this->mode == PageMode::Meta. Ejecuta el código de cada archivo para obtener los metadatos, y sale antes de renderizar el resto. No escalará muy bien si el contenido crece mucho, pero lo ajustaré si se vuelve un problemaTodo el código PHP de mi “framework” son solo cuatro archivos:
init.php,functions.php,Layout.phpyPage.phpLa ventaja de un desarrollador es que puede usar código en lugar de configuración o datos. También puedes usar código para escribir contenido de forma más eficiente
El resultado todavía está bastante incompleto, pero aquí está: https://www.codaris.com/
include()del encabezado y algunos fragmentos globalesSi piensas en la experiencia de usuario desde la perspectiva del dueño del sitio web, esto no es una gran paradoja. WordPress hace que el trabajo sea absurdamente fácil, aunque el overhead sea mucho mayor
Solo parece una paradoja si lo ves como un trade-off frente a dedicar tiempo a configurar distintas cosas. Para la mayoría de la gente, la alternativa es pagarle a alguien para que les haga el sitio web
Si hicieras un editor WYSIWYG para Hugo y lograras que todo, desde registrar el dominio hasta publicar el sitio, se resolviera con unos cuantos clics, podrías ganar mucho dinero
Entiendo a qué te refieres. Aunque se parezca a lo que dicen esas empresas, si alguien pudiera encargarse de esos pequeños pasos intermedios, sería una gran ventaja para algunas personas
[1] https://micro.blog
La parte de “Cuando lanzamos SuperHTML, nos dimos cuenta de que era el primer language server para HTML que reportaba diagnósticos al usuario. Escribí una entrada de blog, llegó a la portada de Hacker News y nadie me corrigió, así que debe ser cierto” probablemente se debe a que la mayoría de los IDE ya hacían eso desde hacía años, incluso antes de que Microsoft publicara LSP
Vim, Neovim, Helix, Zed y VSCode compartían la misma implementación básica sin soporte de diagnósticos
Helix planea activar SuperHTML por defecto a partir de la próxima versión: https://github.com/helix-editor/helix/pull/11609