La eterna discusión sobre si es mejor escribir HTML a mano o usar generadores de sitios estáticos (SSG) sigue siendo un tema candente en la comunidad de desarrolladores. Uno de los argumentos principales a favor del uso de SSG es la capacidad de automatizar tareas repetitivas como la generación de cabezales y pies de página, la creación de feeds RSS, y la creación de páginas a partir de plantillas. No obstante, algunos desarrolladores, cansados del mantenimiento y la complejidad de estos generadores, están volteando sus miradas hacia un enfoque más tradicional: la escritura manual de HTML.
Uno de los comentarios más persuasivos en el debate fue el de superkuh, quien comentó que añadir entradas manuales a un feed RSS no es tan complicado como podría parecer al principio. De hecho, proporcionó un ejemplo de código para demostrar la facilidad de esta tarea.
<item> <title>No es tan difícil</title> <link>http://www.superkuh.com/this-link-doesnt-exist</link> <description>Este es un ejemplo de cómo rápidamente puedo añadir un nuevo ítem a mi feed RSS.</description> </item>Sin embargo, otros desarrolladores señalan que esta simplicidad se desmorona cuando hay que mantener actualizaciones frecuentes y consistentes en un sitio web.
El proceso de transición de generadores como Jekyll a soluciones más simplificadas como Hugo o Zola también recibió numerosas menciones. Mikae1, por ejemplo, destaca cómo migró de Jekyll a Hugo debido a la complejidad y problemas de mantenimiento asociados con Ruby y su ecosistema de paquetes. Según él, el uso de binarios únicos como los que ofrece Hugo reduce significativamente los problemas relacionados con las dependencias y la configuración del entorno.
Otra perspectiva interesante vino de la mano de aquellos que encuentran en lenguajes de plantillas como ERB una solución intermedia. skgough y freedomben coincidieron en que ERB es fenomenal para generar sitios estáticos de manera eficiente, especialmente considerando que las dependencias adicionales son mínimas y las plantillas ERB están bastante alineadas con HTML, lo cual facilita el trabajo.
Pero no todo es tan sencillo como parece. Numlocked enfatiza la importancia de la modularidad, destacando que uno de los grandes beneficios de usar SSG es la capacidad de trabajar con HTML parciales. Por ejemplo, tener una única fuente para la navegación permite mantener la coherencia y facilitar actualizaciones globales. Sugiere el uso de servidores web con soporte para server-side includes (SSI) como nginx o apache como una solución viable, aunque otros comentarios resaltaron la complejidad en la configuración de estos servidores comparada con la simplicidad de utilizar herramientas como 11ty o incluso subir archivos a un bucket S3.
Finalmente, algunos desarrolladores sugieren la integración de herramientas modernas con enfoques más tradicionales para obtener lo mejor de ambos mundos. Por ejemplo, el uso de web components o incluso soluciones basadas en JavaScript para incluir partes comunes de manera dinámica. Un ejemplo sería el uso del objeto <include> para cargar secciones como cabeceras o pies de página directamente en HTML5, aunque esto también introduce sus propios desafíos en términos de rendimiento y compatibilidad.
En síntesis, la elección entre escribir HTML a mano o utilizar un SSG depende en gran medida del contexto y las necesidades específicas del proyecto. Mientras algunos valoran la simplicidad y el control manual, otros prefieren la automatización y las facilidades que ofrecen los generadores de sitios estáticos. Pero lo que queda claro es que la discusión no es solo técnica, sino también filosófica, tocando aspectos de mantenimiento a largo plazo, facilidad de uso, y el balance aceptable de complejidad por funcionalidades. Parece que, al final del día, la elección entre uno y otro método recae en un balance muy personal entre conveniencia y control.
Leave a Reply