Jekyll: construyendo una web estática

Una vez más he perdido el control de mi blog.

Este blog comenzó siendo XML que se compilaba a HTML. El resultado era inmantenible y tenía que hacer mil maravillas para seguir escribiendo.

Más tarde lo pasé a Drupal , aunque no terminé muy contento con él, ya que el spam me comía todo el tiempo.

Para solucionar el problema del spam, migré a Blogger , donde no sólo perdí el control de los posts, sino también de mis artículos.

Hace poco pregunté en Crysol por algún sistema para llevar el blog… Y el resultado ha sido mucho más.

En Crysol me recomendaron Jekyll . Es el motor de generación de las páginas de GitHub , y hay montones de webs que lo usan.

Pero lo que yo quería era un site dinámico, con comentarios, publicidad dinámica,… Pues todo esto no es problema. Basta con identificar qué cosas son estáticas y qué dinámico. El resultado es un site en el que el contenido de los posts es estático, pero se pueden utilizar herramientas externas para gestionar el resto de elementos.

Formatos

Textile

Escribir HTML es duro. Sobre todo si hay código y quieres que éste esté coloreado. Por esa razón apareció Textile (markup_language).

La idea inicial era utilizarlo en wikis, aunque la idea cuajó y se ha extendido a… casi cualquier cosa. Hoy día hay bastantes formatos que permiten generar HTML, pero Textile ha tenido una acogida privilegiada.

Trabajando con Jekyll puedes utilizar Textile para escribir tu código. El resultado es mucho más claro que usar HTML en bruto. Más tarde, Jekyll hará todo el trabajo de generación del HTML.

Además, Jekyll trabaja bien con Pygments , una librería python que permitirá el resaltado de sintaxis de casi cualquier lenguaje de programación.

Plantillas

Otro problema típico de HTML es que no permite importar archivos externos. Siempre puedes hacerlo con Ajax, pero el resultado será aún más complejo de manejar.

Jekyll lo soluciona magistralmente, mediante el uso de layouts, que podemos combinar con plantillas. No entiendo muy bien por qué los han separado, pero parece que las plantillas son más estáticas y específicas, mientras que los layouts están más orientados a la maquetación genérica de la página.

Estas plantillas están escritas en HTML con algunas marcas que permiten introducir código Ruby . No hay que descuidar que Jekyll está escrito en Ruby.

Existen plugins que permiten utilizar HAML en lugar de HTML, lo que resulta de gran utilidad… o un infierno, según se use.

Este lenguaje infernal resulta altamente adictivo: eliminamos la duplicación de HTML (abriendo y cerrando tags) en pro de un lenguaje indentado. Resulta muy curioso que la gente de Ruby, que critica la indentación de Python, sacara este lenguaje basado en YAML.

Hojas de estilo

Otro problema habitual de las páginas web es la creación de hojas de estilo o CSS . Por eso se puede hacer un apaño mediante Rake o Make y utilizar SASS en su lugar. Hay gente que ha acoplado SASS al motor de Jekyll mediante plugins.

Al utilizar SASS dispondremos de nuevas herramientas, como herencia, pseudo-funciones, variables,… que nos facilitarán la vida a la hora de construir las hojas de estilo. Este formato, parecido a CSS, permitirá la generación final de CSS bastante buenas, aunque podrían mejorarse.

Jerarquía

La jerarquía utilizada por Jekyll es la siguiente:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

.
|-- _config.yml
|-- _includes
|-- _layouts
|   |-- default.html
|   `-- post.html
|-- _posts
|   |-- 2012-04-09-post1.textile
|   `-- 2012-04-09-post2.html
|-- _site
`-- index.html

Explico cada uno de los archivos/directorios:

• _config_yml es un archivo YAML de configuración del site.
• _includes es un directorio donde se guardarán las plantillas.
• _layouts es otro directorio donde se guardarán también plantillas. Éstas gozan de ciertos privilegios, como que pueden usarse directamente desde los posts.
• _posts es un directorio donde guardar los posts. Al principio, tendrán cierta información que permite insertar variables de entorno previas al procesado del fichero.
• _site es el lugar donde se dejará el site generado.
• index.html es un HTML que puede usar layouts o includes y que generará el index.html definitivo.

¡Me gusta!

Pues si quieres saber más, basta con visitar la web de Jekyll . Los primeros pasos para trabajar con Jekyll están muy bien explicados.

Pero… ¿por qué tu web no está escrita en Jekyll?

Lo estará. He comenzado. Este artículo ya lo he escrito directamente en Jekyll y después lo he portado aquí.

Tenéis que entender que tengo que currarme el estilo (ya está casi listo), plugins para que Jekyll haga lo que yo quiero, maquetación,… y todas esas cosas que no me han hecho falta con Blogger. Además, lo más pesado: Blogger no permite una gestión automática de sus posts (ya que tiene límites y te reformatea lo que le viene en gana), así que los tengo que pasar a mano. Hay más de 100 artículos, así que tardaré un poco. Aunque pudiera automatizarlo, hay enlaces por cambiar.

¿Tantas ventajas tiene?

La mayor de las ventajas es muy simple: permite gestionar los posts mediante un repositorio tipo GIT. Eso es exactamente lo que yo estaba buscando.

A parte de eso, le he visto otras muchas:

• Es fácilmente ampliable mediante plugins.

• Muy versátil y adaptado a blogs.

• Aunque está orientado a blogs, permite la generación de cualquier site.

• Todo queda bastante bien estructurado.

• Tiene un gestor de artículos relacionados.

• El contenido dinámico se puede insertar mediante servicios externos o JavaScript/Ajax.

• El proyecto puede almacenarse en un sistema de control de versiones tipo GIT. Esto permite muchas ventajas:

  • Puedo automatizar el despliegue de la aplicación cuando haya contenido nuevo.
  • Puedo editar el contenido en el tren.
  • Puedo comparar versiones.
  • Puedo copiar y pegar.
  • Puedo desplegar en local.

• Jekyll tiene su propio servidor web para poder probar el site.

Pero… ¡algún inconveniente tendrá!

Efectivamente. Utiliza formatos totalmente acoplados con Ruby. Si quieres hacer algo avanzado, tienes que hacerlo con Ruby. No hay manera de usar otro lenguaje.

El uso de “su” Textile utiliza órdenes que sólo pueden ser órdenes Ruby, ya sean internas de Jekyll o plugins propios. Si utilizas HAML, te has acoplado aún más al lenguaje. SASS, por el contrario, puede utilizarse sin estos miedos.

La utilización de plugins está acoplada por defecto con el proyecto, aunque existe una manera sencilla de desacoplarlo mediante configuración.

No es paquete Debian, aunque resulta sencillísimo instalarlo mediante gemas.

Además, aunque la documentación básica es bastante buena, la documentación avanzada es, simplemente, inexistente. A menudo pasa por buscar mucho y leer código.

Y lo peor: cuando se genera el site, se genera entero. No admite generar sólo un archivo. En cierto modo, es lógico, ya que la inclusión de un nuevo artículo puede repercutir en el resto (tablas de contenidos, artículos relacionados), pero cuando tienes bastantes artículos y sólo quieres ver un borrador, puede resultar muy tedioso.