Migrar de Jekyll a Hugo

Voy a ser sincero. Migrar de Jekyll a Hugo no fue tan fácil como pensaba.

El primer problema fue entender la estructura de carpetas. El manual de Hugo no era muy claro sobre cuál era la mejor práctica. He descubierto que necesitas al menos tres archivos. Necesitas un ‘home.html’ para la portada, que debes colocar en tu carpeta ’layouts’. Además necesitas dentro de ella un archivo ‘page.html’ y otro ’list.html’. Su nombre te dice lo que hacen: listar el contenido de un tipo de contenido concreto (sección) y mostrar un único archivo de contenido. Si quieres una plantilla de listado alternativa para ‘posts’ (o para cualquier otro tipo de contenido, llamado ‘sección’), simplemente crea una carpeta en tu carpeta ’layouts’ con el nombre de tu tipo de contenido, en este caso ‘posts’.

El segundo problema fue el lenguaje de plantillas de Go. No es nada evidente y me costó muchísimo hacerlo funcionar. Por ejemplo {{ if gt (len . ) 0 }} resulta ser válido en el ’lenguaje de plantillas de Go’. Tienes que saber que en este lenguaje la función siempre va primero. El ejemplo {{ if gt (len . ) 0 }} significa literalmente ‘si | mayor que | longitud del elemento actual | cero’. Tienes que entender que esto significa ‘si la longitud del elemento actual es mayor que cero’. Desde el punto de vista del lenguaje y la gramática esto no es muy lógico. Se convierte en un dolor de cabeza enorme cuando se trata de instrucciones algo más complejas, como esta: {{ if and (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}}. La notación no se parece a ningún otro lenguaje que conociera, lo que hacía muy difícil implementar incluso lógica básica (a pesar de mis 10 años de experiencia programando). La curva de aprendizaje de Go es extremadamente pronunciada. Amber y Ace no ayudaron.

El tercer problema fue Forestry.io. Había estado usando CloudCannon con Jekyll y resulta que estaba malacostumbrado. Forestry tiene ideas muy concretas sobre cómo debe estar formateado mi markdown. Por ejemplo, exigen una línea vacía al final del bloque YAML / front matter. Además, el contenido debe empezar inmediatamente después del final del front matter. Ahí no se permite un salto de línea. No seguir su estilo de código provocaba de todos modos actualizaciones de código no deseadas que lo imponían, lo que suponía un pull y un merge extra por cada push que hacía. Además, sus actualizaciones rompieron mi código más de una vez, porque tenían problemas al parsear archivos SVG inline grandes. Usar Forestry.io se siente como trabajar con un compañero cabezota. Poco agradable, por decirlo suavemente. Pero no debería quejarme demasiado… porque es bastante increíble que su servicio sea gratis (y la mayoría de la gente TIENE de verdad compañeros cabezotas, y también se las apañan).

Pero bueno… mi web Jekyll Codex tarda 1425 milisegundos en construirse, mientras que esta web se construye en menos de 100 milisegundos. Eso es más de 10 veces más rápido. Algo debe valer eso.