Blog mínimo viable (Minimum viable blog)

 (ostwilkens.se)
6 puntos por GN⁺ 2025-05-04 | 5 comentarios | Compartir por WhatsApp
  • El objetivo es crear un blog personal como página estática sobre un dominio ya propio, con una implementación mínima que permita agregar contenido y cubrir SEO básico
  • La implementación sigue un flujo simple: un pequeño template.html, markdown2, un render.py creado pidiéndoselo a O1, y redacción de posts en Markdown
  • La plantilla usa solo HTML/CSS básico, como system-ui, ancho máximo de 70ch, color-scheme: light dark, viewport y UTF-8
  • render.py convierte ./posts/{post}/eng.md a HTML, ajusta las rutas de las imágenes y luego genera ./blog/{post}.html e index.html
  • Muestra que, sin Jekyll, Ghost ni WordPress, se puede crear un blog operable solo con renderizado estático y hosting

Requisitos mínimos del blog y configuración real

  • El punto de partida fueron cuatro requisitos
    • Usar un dominio que ya se posee
    • Seguir estándares web modernos y tener un SEO decente
    • Que agregar contenido nuevo sea muy fácil
    • Que todas las páginas se generen de forma estática
  • El flujo real de implementación es simple
    • Escribir un pequeño template.html
    • Ejecutar pip install markdown2
    • Pedirle a O1 un script render.py
    • Escribir el post, renderizarlo y alojarlo
  • No se usa ningún motor de blog existente como Jekyll, Ghost o WordPress

Plantilla y script de renderizado

  • template.html contiene solo la estructura básica de un documento HTML y el CSS mínimo
    • Define el esquema de colores claro/oscuro con color-scheme: light dark
    • El estilo del cuerpo se configura con system-ui, sans-serif, ancho máximo de 70ch, interlineado de 1.5 y tamaño de fuente de 1.25em
    • Usa un enlace a inicio con id="head-link" y el marcador de posición {{ content }}
  • render.py convierte los posts en Markdown a HTML con markdown2
    • El directorio de entrada es ./posts y el de salida es ./blog
    • Cada post se lee desde ./posts/{post_directory}/eng.md
    • El primer encabezado # se usa como título del post
    • Convierte Markdown con las opciones fenced-code-blocks y header-ids
    • Cambia los <img src=" de las rutas de imágenes para que tomen como base /posts/{post_code}/
    • Reemplaza {{ content }} en la plantilla por el HTML convertido y también cambia la cadena del título por el título del post
  • La página de índice también se genera con el mismo script
    • Primero convierte greetings.md a HTML
    • Lee el título de cada post y agrega una lista de enlaces a /blog/{post_code}.html
    • Guarda el resultado final como index.html
  • El post se escribió manualmente el 2025-03-31

Lecturas relacionadas

5 comentarios

 
ifmkl 2025-05-07

Yo también estoy manejando mi blog justo de la misma manera que arriba. Uso un SSG que hice para cubrir mis necesidades personales. Le fui agregando funciones personalizadas para aprovechar características como imagen de miniatura, categorías y etiquetas. Las imágenes adjuntas las convierto automáticamente a webp para referenciarlas, y gracias a eso la velocidad de renderizado me tiene muy satisfecho.
 
winterjung 2025-05-07

Oh, entonces esas funciones personalizadas, ¿las van agregando ustedes mismos escribiendo el código directamente? A mí también siempre me tienta hacerlo todo DIY, pero termino dudando por las extensiones y funciones de plugins que ofrecen los frameworks de blogs SSG que ya venía usando.
 
ifmkl 2025-05-07

Si dejas de lado la ambición, o mejor dicho, con solo quitarle un poco de ambición, el resto no es tan difícil. Incluso con ssg, si se lo pides a la IA, te escribe todo el código, y si le pides que agregue funciones, la verdad es que también las añade todas jaja
 
ndrgrd 2025-05-04

Si solo eliges una tipografía bonita, termina viéndose bastante bien.
 
GN⁺ 2025-05-04
Opiniones en Hacker News

  • Me vino a la mente el gráfico de esta entrada de blog: https://molodtsov.me/2023/02/how-to-start-your-blog-in-2023/
    Al caer en el pantano de los generadores de sitios estáticos (SSG), terminé pasando la mayor parte del tiempo escribiendo sobre el SSG en sí y trasteando con él, en lugar de escribir lo que originalmente quería o hacer lo que pensaba hacer
    Al final dejé el SSG, instalé WordPress y dejé de preocuparme; fue una gran sensación de liberación
    Si tu objetivo es trastear y escribir sobre el proceso, está bien; también está bien para quienes el trasteo no les impide escribir, pero no era mi caso
    Lo último que necesitas justo cuando vas a escribir es una excusa para postergarlo

    • WordPress en 2025 tiene dos características peligrosas a la vez
      WordPress y todos sus plugins pueden verse comprometidos si no se mantienen actualizados, y el BDFL es alguien que puede bloquear la entrega de actualizaciones de seguridad o el acceso para recibirlas por motivos personales triviales
      En un sitio estático no hay vulnerabilidades de seguridad que parchear, así que aunque un proyecto SSG se derrumbe por completo por problemas de su administrador, no importa demasiado; pero en WordPress eso se vuelve muy importante
    • A mí me pasó algo parecido. Hace mucho empecé con DokuWiki, luego decidí probar GitHub Pages y, después de migrarlo todo, necesité búsqueda, así que agregué una búsqueda personalizada de Google
      Necesitaba una forma de que los visitantes dejaran comentarios, así que agregué Disqus, y al final terminó siendo un revoltijo de varios servicios y mucho JavaScript
      Hace unos años, para volver a ser dueño de mis datos y no depender de servicios externos, exporté los comentarios de Disqus, estuve probando Serendipity y terminé quedándome con WordPress
      Pude importar los comentarios y las páginas en Markdown, y también había un plugin que publicaba todo en el Fediverse
      Lo hice funcionar con SQLite y dejé activadas las actualizaciones automáticas, así que en la práctica ya no requiere mantenimiento
    • ¿Spam de blog? :) La URL es https://rakhim.org/honestly-undefined/19/
    • Estoy de acuerdo, pero creo que en el 95% de los casos WordPress es excesivo
      Requiere demasiado mantenimiento por funciones que probablemente no necesitas. Si no lo mantienes actualizado, puedes terminar siendo parte de una botnet
      Para la mayoría de los blogs basta con un generador de sitios estáticos, y si requiere mantenimiento, puedo hacerlo cuando yo quiera
    • Estoy bastante satisfecho con nikola: https://getnikola.com/
      Lo que realmente quería era un solo comando para publicar y una forma sencilla de arrastrar y soltar imágenes en los posts; lo primero funciona bien y lo segundo es posible con la función de publicación de Jupyter Notebook
      Lo que definitivamente no quería era una forma de “enviar HTML al cliente” que trajera consigo una carga como una base de datos

  • Está bueno, pero siento que le hacen falta dos pequeñas funciones más para llamarlo blog
    Primero, las entradas deberían ordenarse por fecha, mostrando las más recientes primero, y la fecha debería aparecer en algún lugar. Para mantener la configuración mínima, se podría usar la metadata del archivo de la entrada, por ejemplo la hora de creación
    Segundo, por supuesto, necesita un feed RSS. Con el script existente y una plantilla RSS mínima, parece fácil crear un feed simple que solo incluya enlaces y títulos

    • RSS está bien, pero no creo que deba ser un requisito para que algo sea considerado un blog
      Que te “sigan” no siempre es algo bueno y puede generar presión para complacer a los lectores. Es precisamente el mismo factor que hace malas a las redes sociales
    • Tiene sentido
      Para el punto 1, me estoy inclinando por generar automáticamente un archivo con metadata en algún formato como TOML
      Definitivamente voy a agregar RSS para el punto 2, pero depende del punto 1 :-)

  • Siempre me han gustado los sitios web independientes, y mi propio sitio empezó de forma parecida hace unos 25 años.
    En aquel entonces, la única tecnología adecuada que conocía era Classic ASP, así que lo hice de forma simple y mínima, solo con ASP.
    Ahora funciona como un sitio generado estáticamente con Common Lisp, y creo que esta configuración será la definitiva a largo plazo: https://github.com/susam/susam.net/blob/main/site.lisp
    Empezar con un conjunto simple de páginas fue una buena manera de crear un sitio web mínimo viable, pero con el tiempo hicieron falta funciones como feed RSS, lista de posts del blog por fecha, índices por etiqueta, soporte para contenido que no es de blog como herramientas, juegos y demos, y comentarios sin terceros.
    Cada vez que crecían los requisitos también crecía el código fuente, y lo que eran unos cientos de líneas ahora son unas 1300 líneas de Common Lisp.
    Aun así, quiero mantenerlo en un nivel en el que pueda tener todo el código en la cabeza de una vez y, si aparece un bug, razonarlo y corregirlo en menos de 10 minutos.
    Últimamente me tienta agregar un blogroll con la lista de publicaciones de mis blogueros favoritos. Podría incluso reemplazar a un lector de feeds, pero estoy tratando de tener cuidado de que no crezca hasta convertirse en algo que también lea el correo electrónico.

    • Seguí casi el mismo camino.
      El código fuente está aquí: https://github.com/brilee/modern-descartes-v2/blob/master/ma...
      Incluye feed RSS, lista de posts por fecha, sistema de etiquetas y un servidor de desarrollo local con recompilación mediante vigilancia de archivos.
    • Mi camino también fue parecido; de hecho, lo he repetido varias veces.
      La versión actual se mantiene como un script de Python de menos de 1000 líneas: https://github.com/llimllib/obsidian_notes/blob/c93b9b5c46fe...
    • Exactamente esto. La capacidad de decidir “quiero construir este dispositivo” y programarlo uno mismo es mejor que cualquier WYSIWYG.
      Creé páginas derivadas como recopilaciones de posts, índices y presentaciones, y también variaciones de etiquetas para personas y videojuegos.
      También se puede controlar por completo el aspecto y la sensación de widgets comunes como galerías de miniaturas o cajas de citas.
    • Creé en Lamb una función llamada Flock, que sindica feeds hacia mi blog. La hice sobre todo como alternativa a un enfoque multiusuario: https://github.com/svandragt/lamb
      Podría servir como referencia de alto nivel.
    • RSS y las fechas seguramente harán falta.
      Más adelante quizá quiera embeber shaders y juegos web, pero espero que la complejidad no crezca demasiado.

  • Me gustaría que los navegadores soportaran text/markdown y text/gemini de forma nativa.
    Si un navegador puede renderizar PDF, no parece tan difícil incluir un formateador simple para contenido Markdown/Gemini y una hoja de estilos configurable por el usuario.
    Hoy todavía se puede tener un blog en text/plain, pero no es hipertexto real y se pierde en SEO. Tal vez se pueda hacer algo de magia con el header link.
    Soportar otros formatos reduciría la barrera para publicar de forma limpia y devolvería el control al usuario.

    • El renderizado de Markdown nativo en el navegador sería bueno, pero lamentablemente parece poco probable.
      Primero los navegadores tendrían que ponerse de acuerdo sobre qué variante y extensiones de Markdown usar. Markdown es casi como el CSV de los formatos de texto: todo el mundo lo usa a su manera.
      Si lo hacen demasiado mínimo, la gente se quejará de que no sirve; si eligen extensiones, se quejarán de que está inflado.
      Incluso si uno intenta debatir con cuidado los pros y contras a corto y largo plazo, puede quedar bloqueado por frases como “no dejes que lo perfecto sea enemigo de lo bueno”.
      Aunque se acordara un conjunto concreto de funciones, también es dudoso que realmente valga la pena.
      Leer PDF directamente en el navegador es bastante común, pero el beneficio de leer Markdown directamente probablemente solo alcanzaría a una parte de los desarrolladores de software del mundo y a unas cinco personas raras.
      Así que no me sorprendería no ver renderizado de Markdown nativo en navegadores durante mi vida.
    • El renderizado de PDF del navegador se hizo con JavaScript, o al menos así fue en algún momento.
      También hay bibliotecas para XSLT que se pueden usar cuando se necesita una versión más nueva que el soporte nativo del navegador, y bibliotecas para varios formatos como jpegxl.
    • ¿Gemini también tiene su propio formato?

  • Si es html_content = html_content.replace('Minimum viable blog', title), ¿cada vez que aparezca la cadena Minimum viable blog en el texto se reemplaza por el título actual del post? ¿No es un bug?

    • Sí, bien visto.
      El código del post era el primer borrador generado por O1, y esa cadena se reemplazó por {{ title }}.

  • He estado experimentando con blogs minimalistas durante unos 15 años y aprendí algunos trucos.
    Algo como const title = lines.match(/# (.+)/)[1] basta, así que se puede evitar el frontmatter.
    Mis blogs nunca han tenido tantos posts como para necesitar paginación, etiquetas, categorías u ordenamiento.
    JSX funciona bastante bien como builder de strings puramente del lado del servidor si usas hacks sospechosos como https://immaculata.dev/guides/enabling-jsx.html.
    Ahora también es fácil usar pasos de build arbitrarios en GitHub Pages en vez de Jekyll, con cosas como https://immaculata.dev/guides/using-gh-pages.html.
    highlight.js es casi el rey del resaltado de sintaxis de código muy fácil, porque basta con agregar tres líneas al HTML; shiki es genial, pero lento.

  • Es fácil si usas un framework estándar de blog estático como Hugo/Zola + Cloudflare Pages
    Mi blog también tiene una configuración mínima de menos de 100 KB y cumple con todos los criterios que enumeró el autor original
    Uso el tema Hugo Blog Awesome, seguí la guía de 512kb y verifiqué el tamaño de las páginas, además de quitar imágenes y JS innecesario. Para empezar, no había mucho
    Referencia: https://512kb.club, https://radar.cloudflare.com/scan

  • Durante un tiempo mantuve un “MVB”, pero el mío era todavía más simple
    Simplemente tenía una sola página HTML, escribía los posts como archivos .txt y actualizaba la página principal manualmente
    Era bastante verboso, pero aun así creo que era más fácil que lidiar con la web moderna
    Después me pasé a algo más sofisticado y ahora uso Astro para mi sitio personal y mi blog, y es realmente excelente
    En su landing page, Astro afirma ser la mejor plataforma para “sitios centrados en contenido”, y después de usarlo 6 meses terminé estando de acuerdo
    Ofrece convenciones claras y fáciles de seguir para casi todo lo necesario para crear un blog, y elimina lo innecesario

    • Astro es realmente impresionante. No entiendo por qué no es más popular
    • Me da curiosidad si usas el tema de otra persona o si lo hiciste tú mismo

  • Experimenté en algunos sitios con Bun JS y HTML dentro de cadenas de JavaScript
    Bun tiene una bandera —hot que vuelve a generar el HTML estático cuando hay cambios
    IntelliJ IDE detecta el comentario // language=html encima de la cadena, y formatea y resalta la sintaxis del HTML interno
    Si usas funciones de JavaScript puro en vez de un lenguaje de plantillas, puedes escribir directamente la lógica que necesitas sin tener que buscar cómo hacerlo en ese lenguaje de plantillas

  • Harto de los sitios web tan pesados que tardan mucho en cargar, estoy usando un enfoque muy parecido en mi blog: https://blog.borrego.dev
    Fuente: https://github.com/agubelu/blog

    • Me gusta mucho y se ve bien. ¿Cómo se ve en móvil?