Crear un sitio web sin frameworks ni varias bibliotecas

 (kodingkitty.com)
3 puntos por GN⁺ 2023-07-05 | 1 comentarios | Compartir por WhatsApp
  • Koding Kitty aplicó un stack centrado en HTML estático para el sitio web de una pequeña empresa, y opera las páginas necesarias y un blog sin un gran CMS ni frameworks
  • Los criterios de elección fueron velocidad, facilidad de desarrollo, hosting barato y baja complejidad; WordPress, no-code, frameworks y Jamstack implicaban demasiada configuración y carga de aprendizaje para sus requisitos
  • El contenido se escribe directamente en HTML en lugar de Markdown o un editor visual, lo que facilita manejar publicaciones que combinan texto y widgets HTML/CSS/JS
  • Las estructuras repetidas y los bloques comunes se manejan con plantillas Jinja, y un script de Python de 45 líneas encadena la detección de cambios, el renderizado de HTML y la llamada a Tailwind CSS CLI
  • Al ser un sitio estático, basta con hosting barato; el web hosting de Hetzner empieza desde 2 EUR y soportó picos de tráfico de la portada de Hacker News

Por qué eligieron un stack simple

  • El stack tecnológico del sitio web de Koding Kitty no sigue tanto la moda reciente del desarrollo web ligero, sino que está configurado deliberadamente de forma simple según sus necesidades reales
  • El objetivo era una configuración con poca fricción para el desarrollador, y consideraron que una solución simple podía ser mejor para los clientes que una combinación compleja de frameworks y bibliotecas
  • Un diseño distintivo pero no exagerado podía construirse de varias maneras, pero la configuración actual es una elección ajustada al alcance necesario

Requisitos y criterios iniciales

  • Desde el principio decidieron crear un sitio web estático
  • Las funciones necesarias eran básicamente una página principal, una vitrina y un blog, y no mucho más
  • Los criterios eran cuatro
    • Sitio web rápido
    • Desarrollo rápido
    • Hosting barato
    • Complejidad mínima

Opciones evaluadas pero descartadas

  • WordPress y CMS similares

    • Reconocen que WordPress ha tenido un papel importante en Internet
    • Pero era excesivo para unos requisitos modestos
    • No necesitaban guardar el contenido en una base de datos, ni plugins ni un editor visual

  • Herramientas no-code

    • Les pareció extraño que un codificador web usara herramientas no-code
    • Querían ser dueños directos del contenido y manejar el sitio web como quisieran
    • Consideraron que hacerlo con código era más rápido que con un editor WYSIWYG no-code
    • La necesidad de aprendizaje inicial y continuo también era una carga

  • Frameworks

    • Tenían experiencia con frameworks, pero no querían traer toda la configuración
    • Podrían acumularse demasiados componentes, como base de datos, configuración, bibliotecas y funciones de administración
    • Aunque se puede personalizar por completo, concluyeron que el resultado podría terminar pareciéndose a WordPress

  • Jamstack y generadores de sitios estáticos

    • Los generadores de sitios estáticos parecían una opción que encajaba bien con los requisitos
    • Permiten elegir un lenguaje, programar y luego crear rápidamente un sitio estático con un botón o script
    • Sin embargo, requerían configuración inicial y aprendizaje inicial y continuo
    • Reconocieron la comodidad de escribir un blog en Markdown, pero en conjunto eligieron una solución más simple

Composición de KittyStack

  • La configuración de Koding Kitty se organizó en torno a los cuatro requisitos

  • Sitio web rápido

    • Un sitio web estático funciona rápido

  • Desarrollo rápido

    • El contenido se escribe en HTML, no en Markdown ni con editores avanzados
    • Como las publicaciones de Koding Kitty mezclan texto y widgets HTML/CSS/JS, escribir HTML directamente era lo adecuado

  • Hosting barato

    • El costo del hosting para sitios estáticos varía según el proveedor y las funciones adicionales necesarias
    • Como los sitios estáticos no requieren una gran configuración de hardware, se puede elegir una configuración mínima
    • Hetzner webhosting empieza desde 2 EUR
    • El sitio de Koding Kitty soportó incluso picos de tráfico del nivel de aparecer en la portada de Hacker News

  • Complejidad mínima

    • Algunas páginas y publicaciones tienen patrones repetidos
    • Sería posible hacerlo copiando y pegando, pero con el tiempo podría volverse difícil de controlar
    • Necesitaban bucles e inclusión de bloques de código como headers y footers

Jinja y flujo de build

  • Las estructuras repetidas y la inclusión de archivos comunes se manejan con plantillas Jinja
  • Jinja ofrece bucles, inclusión de archivos como la barra de navegación y el footer, y otras funciones de plantillas
  • El equipo ya había usado frameworks basados en Jinja en el pasado, así que no tuvo que aprender un sistema nuevo

Cadena de herramientas simple

  • Las páginas estáticas finales se generan con un script de Python de 45 líneas
    • El conteo de líneas incluye comentarios y líneas en blanco
  • El flujo de build es el siguiente
    • El desarrollador modifica index.src.html
    • Watchdog.py detecta cambios en los archivos
    • Renderiza la plantilla Jinja como index.html
    • Llama a Tailwind CSS CLI para generar styles.min.css
  • Durante el desarrollo, Live Server sirve los archivos y recarga cuando hay cambios
  • Al momento de desplegar, los archivos se suben manualmente por FTP

Ventajas de un desarrollo web menos complejo

  • El desarrollo web puede mantenerse simple sin sacrificar muchas cosas
  • Limitar las opciones a unas pocas puede, de hecho, sentirse más libre
  • Para muchos clientes, una solución más rápida, más simple y más barata puede ser útil
  • Conviene observar el panorama web en general y evaluar si se puede lograr el mismo resultado con un stack tecnológico menos complejo

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-07-05
Comentarios en Hacker News

  • Un portafolio de fotografía también terminó asentándose con el mismo enfoque. Como pasé de desarrollo a fotografía, una ventaja es que no tengo que depender de Squarespace como otros fotógrafos
    Después de probar varias opciones basadas en servidor hechas con Ghost, Statamic y Phoenix/Vapor, además de los generadores de sitios estáticos habituales, al final terminé escribiendo HTML puro sin plantillas y subiéndolo a un servidor de Hetzner con rsync
    Que no haya plantillas para UI compartida como la navegación sí molesta un poco, pero todavía no ha habido cambios que me tomen más de unos minutos con expresiones regulares, y una vez al principio un regex codicioso borró contenido, pero git me salvó
    Generar variantes de imágenes por tamaño y formato es fastidioso, pero me permite probar nuevos layouts sin depender de estructuras rígidas como la de Ghost. Además, al exportar imágenes para web, el editor RAW Capture One me pareció dar una calidad ligeramente mejor que las librerías o herramientas CLI que usan la mayoría de los generadores de sitios estáticos
    Es más lento, pero lo veo más cercano a hacer un fotolibro. Al principio requiere más trabajo manual, pero una vez que queda terminado, queda terminado, y no hace falta ir saltando entre distintos CMS durante los próximos 20 años y romperlo todo

    • La navegación básica de anterior/siguiente y menús, encabezados y pies de página consistentes se pueden manejar con server-side includes
    • Mi sitio personal de fotografía usa Svelte + TailwindCSS, la API de Flickr y Netlify
      En la práctica, es una estructura de unos cuantos archivos HTML potenciados por plantillas; usa la API de Flickr para traer fotos desde un álbum exclusivo para este sitio, y Netlify despliega automáticamente con solo hacer git push
      El costo total, incluyendo hosting, es de 0 dólares, y con la app de Flickr puedo administrar fotos desde el celular. También me gusta que con Netlify no hace falta tocar un servidor real
    • Me da curiosidad cómo fue la experiencia usando Vapor
      Lo que usé hace poco también podría servir(https://news.ycombinator.com/item?id=36592641). Usar Google Sheet como fuente de datos fue fácil, y seguramente habría sido igual cambiándolo por un sistema de archivos de fotos
    • Justo estaba pensando en dejar Smugmug para probar algo así; me pregunto si podrías compartir tu portafolio o el código fuente

  • Esto no parece “simple”, sino más bien simplista. Puedes hacer un sitio web relativamente simple si no haces nada y vas recortando las esquinas
    Basta con ver el modo oscuro, que es casi la única función no trivial visible en esta página: está hecho con JS cargado de forma diferida, así que en cada carga de página hay un parpadeo blanco inevitable. Para hacerlo bien tendría que ser con clases CSS en el body, y una solución que no funciona no sirve ni si es simple ni si es compleja
    Además, traer un intérprete personalizado entero de ‘hyperscript’ como https://hyperscript.org/ solo para 3 líneas de JS de localStorage y la configuración del modo oscuro va en contra de la idea de que “la simplicidad es la máxima sofisticación”. Cargar una librería sin caché de 96 KB únicamente para eso es raro, y me pregunto si por eso tampoco valida el HTML
    Por último, un toggle binario es una mala implementación de modo oscuro porque ignora la configuración del sistema/navegador. Aunque actives el modo oscuro en el sistema operativo del teléfono, seguirá mostrando modo claro hasta que el usuario lo active manualmente, y tampoco respeta configuraciones del sistema que cambian según la hora o la luz ambiental. localStorage puede expirar y además uno cambia de dispositivo, así que hay que configurarlo una y otra vez; probablemente los usuarios no estén de acuerdo con lo que el desarrollador llama una implementación ‘simple’

    • Si la meta es un sitio lo más simple posible, entonces no debería haber modo oscuro. También en los 90 existían sitios simples y legibles, y antes de que se pusiera de moda el modo oscuro, el modo claro era suficiente
      Si empiezas a considerar cosas como configuración del sistema/navegador, cambios por zona horaria o por luz ambiental, la complejidad choca demasiado con la filosofía de un sitio simple. Mejor quitar el modo oscuro; incluso HN está siempre en modo claro y no hay gran problema para leerlo de noche
    • Estoy de acuerdo en que el enfoque con JS diferido está mal, pero el enfoque con media queries también es complicado
      Normalmente quieres respetar prefers-color-scheme y al mismo tiempo ofrecer un toggle, y si el usuario ya eligió manualmente una opción antes en el sitio, quieres priorizar esa elección. Entonces igual necesitas JS y localStorage
      Mi forma preferida es poner un estilo inline con body {visibility: hidden; opacity: 0;}. Puedes mantener visible la página anterior y, cuando llegue DOMContentLoaded, revisar prefers-color-scheme y localStorage, asignar la clase correcta al body y recién entonces renderizar la página
    • Mientras lo leía pensé “qué gran análisis”, y cuando vi al autor entendí por qué. Para decirle al OP: este es el autor de https://gwern.net, un sitio que ha influido mucho en el diseño de muchos blogs técnicos y sitios personales, y tiene muchas ideas originales y excelentes
      Mi sitio respeta los temas claro/oscuro con CSS y no tiene toggle manual. Tengo como meta personal un sitio puro HTML/CSS sin JS, y creo que la configuración de claro/oscuro debe respetar la preferencia del usuario. Si hace falta un toggle, debería estar no dentro del sitio sino en la barra de herramientas del navegador
      Si /u/gwern llega a leer esto, mi sitio https://daveon.design/ recibió influencia del diseño de gwern y de Tufte.css. También mezcla publicaciones antiguas, manuscritos y gustos personales, pero gwern fue el ejemplo clave que primero me inspiró sobre cómo puede verse un sitio personal moderno y limpio, y qué puede contener
    • En Firefox, Chrome y Safari de Mac, y en Firefox y Chrome de Android, no veo el parpadeo blanco. Tanto la carga inicial como el refresh y el cambio entre oscuro/claro parecen funcionar bien sin más
    • Es un punto válido. Por desgracia, esa forma de pensar rota pero que parece simple también está muy extendida, tanto como los enfoques rotos y excesivamente pesados

  • Si tuviera que decirlo, ahora mismo SvelteKit + Skeleton me impresiona muchísimo por la velocidad para crear prototipos realmente utilizables
    Incluso sin conocer bien Svelte, si entiendes el enrutado basado en archivos, casi todo lo demás es prácticamente HTML hasta que lo necesites; además Tailwind viene por defecto y el tema también se siente bastante cercano a vainilla
    En los últimos meses probé varias cosas como Astro, Lit, Next.js, las plantillas integradas de Go, pug y Eleventy, y hasta ahora esta combinación es la que más me gusta en casi todos los aspectos

    • SvelteKit es excelente, pero me cuesta estar de acuerdo con Skeleton. Al principio se siente productivo y seguro, pero tiene muchas trampas, y cuando aparece algo que no te gusta, se vuelve difícil de personalizar
      Basta con ver el propio sitio de Skeleton https://www.skeleton.dev/docs/get-started: aunque presiones Page Down no hace scroll, si pasas el mouse por la barra de navegación tampoco hace scroll, y al imprimir solo se corta la parte visible en pantalla. Ya reporté este problema, pero aunque todavía no parece ser una gran prioridad, muchos sitios siguen usando este patrón de componentes
      Skeleton parece asumir que si inviertes los colores del tema oscuro obtienes un buen tema claro, pero en la práctica no es así. DaisyUI es más maduro, más rápido, más usado y se toma en serio la accesibilidad. También sorprende que logre cosas solo con animaciones CSS, sin JS, y resuelve las partes difíciles de HTML/CSS mientras te deja escribir tú mismo la parte fácil de Svelte. Además, depende poco de Svelte, así que es fácil mover el HTML de DaisyUI a otros frameworks
    • De acuerdo. Aunque es un framework, te permite generar fácilmente un sitio estático que sigue funcionando bien incluso si desactivas JS, puedes usarlo sin conocer Svelte y, si hace falta, también puedes usar Svelte
      Tailwind funciona de inmediato y desplegarlo en algo como Netlify también es muy sencillo. A día de hoy me parece el mejor generador de sitios estáticos, y creo que es mucho más simple que el enfoque explicado en el artículo
    • Como alguien a quien le gusta el minimalismo, he usado Astro y SvelteKit, y SvelteKit se siente como una capa muy pequeña encima de Svelte, que ya de por sí es una librería de componentes muy pequeña
      Con +page.ts y la configuración adecuada, también puedes hacer un sitio web estático, o llevarlo a una app multipágina o de página única
    • No veo muchos ejemplos del estilo “si escribes esto, la página final sale así”. Me gustaría que hubiera ejemplos que uno pudiera revisar de inmediato antes de instalar nada y seguir un procedimiento
    • Buena recomendación. También me gustaría escuchar más experiencias usando otros frameworks web, y me pregunto si probaste Flutter

  • Dios mío, hacer un sitio web con HTML y CSS suena como una locura
    Bromas aparte, salvo por las plantillas uso el mismo stack. Si no eres desarrollador web, no termino de ver la necesidad de un framework CSS, y hacerlo a mano es mucho más fácil. También probé generadores de sitios como Hugo, pero no me ahorraron nada de tiempo
    Hace unos meses, para mejorar mis habilidades con CSS, intenté recrear los sitios web de algunas empresas, y visualmente pude reproducirlos todos solo con HTML y CSS. Pero los sitios reales de esas empresas ni siquiera aparecían si desactivabas JS
    Seguimos apilando frameworks sobre frameworks, lenguajes nuevos y herramientas nuevas, y la mayoría solo aumenta la complejidad y el trabajo de la siguiente generación. El 5% de los sitios web que de verdad necesitan eso son la excepción
    También me pareció interesante que fuera un sitio que vende servicios reales, y me dio curiosidad saber en qué rango estaban los precios

    • Me parece muy difícil diseñar algo y mantenerlo consistente. Por eso ayuda tener CSS predefinido; si no, el resultado termina viéndose desastroso
    • En general estoy de acuerdo, pero con Astro sí he tenido bastante éxito

  • Creo que la forma más minimalista y productiva es simplemente usar PHP, porque ese lenguaje fue creado originalmente para ese propósito
    Si el sitio es simple, no necesitas composer ni lógica de router; basta con separar archivos de header/footer/navigation e incluirlos en cada página

    • Incluso sin librerías puedes hacer un router y un layout en unas 100 líneas. El router solo revisa si existe el archivo, y el layout puede limitarse a incluir header.php, pagename.php y footer.php. Para sitios simples lo hago así, y es muy fácil y rápido
    • No tiene que ser PHP; cualquier lenguaje de scripting del lado del servidor sirve. Lo importante es poder nombrar, guardar y cargar datos y bloques de código para que el sitio se pueda refactorizar
      Si HTML pudiera insertar HTML externo como CSS o JS, incluso esto sería innecesario en la mayoría de los casos. Ojalá simplemente lo permitieran usar libremente
    • Si buscas simplicidad, es difícil superar PHP + HTML. Para algo más grande que un script de propósito único no querría ir tan al extremo y normalmente al menos pondría una librería de plantillas aparte, pero está bien saber que se puede hacer así
    • Estoy de acuerdo con la idea, pero con unas 5 a 20 horas puedes crear un generador de sitios eficaz y personalizado basado en Eleventy y desplegarlo gratis en Netlify
      Modificas algo, haces git commit/push y en menos de 30 segundos los cambios ya están reflejados en todo el mundo. Está bastante bien y no necesitas hosting de servidor aparte
    • Hay muchos frameworks simples, pero en cuanto les agregas unas cuantas cosas más, enseguida vuelven a la hinchazón habitual

  • Me hace pensar en la frase: “tan simple como sea posible, pero no más simple”. Probablemente no sea de Albert Einstein
    HTML + CSS puros, poniendo el CSS dentro de cada etiqueta HTML o dentro de la página, está bien para empezar. Cuando ya son dos páginas, terminas sacando el CSS a un archivo aparte
    Pero cuando empiezas a hacer un sitio con varias páginas del mismo tipo, ya necesitas un sistema de plantillas con include y un generador de sitios estáticos
    Si las páginas están basadas en datos, necesitas un generador de sitios programable que consuma datos y escupa páginas, y si los datos son “en tiempo real”, entonces tienes que generar páginas por vista, así que como mínimo entras al terreno de PHP, y más allá, al de los frameworks web modernos con un servidor corriendo
    Hace poco hice un sitio pro bono relacionado con un hobby. Era un sitio de promoción de baile y eventos, y la dueña es una profesora de baile que no sabe mucho de tecnología. Generé un sitio estático en el plan gratuito de Netlify con Eleventy(https://www.11ty.dev/), y le agregué código de build personalizado para traer datos desde Google Sheet, de modo que la profesora pudiera definir los próximos eventos
    Tomó unas cuantas horas hacerlo, pero ahora funciona bien sin costos de operación ni mantenimiento. Me di cuenta de que hay un punto ideal muy potente entre la configuración mínima total y algo del nivel de Rails/Phoenix/Django

    • Al final, el OP también usa dos librerías: plantillas Jinja y estilos con Tailwind. Es un punto medio razonable entre HTML/CSS puro y Django/Phoenix/Rails + Angular/React/Vue
    • Yo normalmente refactorizo cuando algo aparece dos veces, pero también he oído que con DRY conviene esperar hasta la tercera, porque ahí es donde probablemente se equilibra mejor el costo-beneficio
      Aunque la cantidad de páginas de un sitio casi con seguridad va a pasar de 3, así que puede ser un poco distinto de la probabilidad de que un bloque de código genérico se use 3 veces o más
    • Me pregunto si publicó esto como open source o si encontró un proyecto parecido
      También me pregunto si la estructura consiste en llamar a la API de Google Sheets desde el cliente para llenar los datos y, si es así, si hay una capa de caché o si cada cliente recibe una copia nueva cada vez

  • El debate sobre frameworks y complejidad ya de verdad cansa
    Si el cliente pide un CMS personalizado con flujo de publicación de múltiples etapas, internacionalización y accesibilidad para cumplimiento normativo, necesitas herramientas potentes para construirlo dentro del tiempo que el cliente espera. En el mundo enterprise hay muchos clientes así, y por eso hay tanta demanda por esas herramientas. Si solo has trabajado en B2C, esto te puede sorprender, pero es la parte sumergida del iceberg de la industria tecnológica
    Es cierto que un blog estático no necesita una configuración compleja de Next.js ni una toolchain de Vite. Pero la gente que habla seriamente de estas herramientas no está hablando de hacer un blog sencillo. El ejemplo reducido del tutorial puede ser un blog, pero el problema real es otro
    Así que me gustaría que bajara un poco el odio a los frameworks. Si hay una buena idea para hacer sitios web de forma simple, basta con publicar un tutorial, y si resulta atractiva, la gente la usará donde corresponda. Pero ojalá se evite plantearlo como una oposición contra un enemigo vago de “toolchains picantes y frameworks de moda”

    • Mucha gente que participa en esta conversación nunca ha trabajado directamente con problemas donde estas herramientas sí son útiles. Pueden ser ingenieros, pero no tocar frontend y no saber más que lo básico, o ser estudiantes de CS que hicieron un blog personal con Jekyll y creen que ya entienden todo el desarrollo frontend
      O pueden pensar que ya lo saben todo porque llevan tiempo haciendo una app interna con usuarios de dos dígitos y sin requisitos de UX. Ese tipo de juicios con tan poca información termina desplazando la discusión
    • Si haces algo complejo sin usar frameworks, al final terminas construyendo otro framework por tu cuenta
      Solo que esta vez la persona que herede ese código no va a recibir actualizaciones ni va a poder buscar ayuda fácilmente en Stack Overflow
    • De acuerdo. Lo digo incluso como alguien a quien no le gusta la complejidad que introducen los frameworks
      No entiendo por qué se asume que no se pueden usar herramientas distintas para trabajos distintos. Hay veces en las que no necesitas un framework, pero en mi experiencia son raras, a menos que estés haciendo algo muy simple y que no vaya a cambiar mucho
      Cuando hay un equipo y un cliente, me cuesta imaginar cómo funcionaría un sitio de “herramientas simples”, y no lo digo como crítica, de verdad no lo sé

  • Incluso esto ya me suena demasiado complicado
    Escribo los textos en Gemtext, o sea, markdown para Gemini, e hice un script en Python que los convierte a HTML y genera la página de índice
    El CSS tiene solo 42 líneas, así que lo metí en cada página, y calculé que el costo de agregar 42 líneas por archivo nunca iba a ser mayor que el de una segunda petición HTTP
    Fue mucho más simple de lo esperado, sin librerías de Python ni plantillas. La parte más difícil fue generar los correos para enviar a la lista de correo. Pasé meses analizando varios frameworks y generadores de sitios estáticos, y semanas buscando un CSS decente
    Según el historial de git, lo terminé tras dos semanas de meterle mano, incluyendo traer 18 años de historial de WordPress. Como es Python puro, no tuve que aprender nada nuevo, y si hay un bug puedo arreglarlo o cambiarlo fácilmente. Porque es mi código
    Los científicos de la computación se han olvidado por completo de que uno puede simplemente programar una solución temporal a medida en vez de intentar reutilizar todo. El tiempo de aprender y adaptar es mayor que el tiempo de hacerlo directamente
    Código: https://git.sr.ht/~lioploum/ploum.net
    Sitio: https://ploum.net

    • ¿Correo? ¿Script en Python? ¿Git? Excelente máquina de Rube Goldberg
      Mi sitio lo sirve un procesador 6502 tallado en madera balsa en 2003 y pegado con epoxi a un cable Ethernet. Cuando quiero cambiarlo, caliento la EPROM con una secadora para que se volteen los bits que quiero. Sin plantillas, sin código, sin bloat
    • Excelente blog. Lo abrí solo para ver el diseño y terminé leyendo cuatro publicaciones seguidas
      Ir bajando y repasar la historia de la tecnología provoca una sensación de nostalgia

  • Si no lo entendí mal, no parece muy distinto de un generador de sitios estáticos promedio. Se ve como la diferencia entre crear archivos HTML con plantillas Jinja basadas en Python y Jekyll, que crea archivos HTML/Markdown con plantillas Liquid basadas en Ruby

    • En vez de usar un framework ya existente, hizo uno propio. Y eso está bien. Crear cosas es divertido
    • Yo pensé lo mismo. Si el objetivo era la simplicidad, parece una elección extraña haber hecho un generador personalizado en lugar de usar un generador de sitios estáticos existente
      Creo que un sitio en PHP con include o un generador de sitios estáticos ya hecho tendría mucho más sentido

  • No lo entiendo. Es como no querer un generador de sitios estáticos, así que terminó usando un generador de sitios estáticos hecho por él mismo