Pourquoi j’utilise Hugo pour mon site

Suite aux nombreuses difficultés rencontrées avec Angular dans la conception du site AngularChef, j’ai décidé de me tourner vers le générateur de site statique Hugo. Pourquoi j’ai choisi Hugo ? Dans quels domaines excelle-t-il ? Quelle sont ses limitations ?

Mon cahier des charges pour AngularChef

Voici la liste des fonctionnalités dont j’ai absolument besoin.

Pouvoir publier des tutos Angular avec un workflow simple. En tant qu’unique auteur du site, je suis content avec deux statuts publié/non publié. Je veux pouvoir formater mes tutos en markdown et insérer des extraits de code avec coloration syntaxique. Je veux pouvoir mettre en ligne

Avoir un site optimisé par la SEO et le partage sur les réseaux sociaux. Autant c’était compliqué à mettre en place avec Angular, autant c’est facile avec Hugo. Le site étant statique, il est parfaitement indexé par les moteurs de recherche et les bots des réseaux sociaux. Puisque je contrôle le HTML, je peux facilement insérer tous les meta tags qui boostent le référencement.

Contrôler le HTML

Publier des contenus avec un workflow simple

Coloration syntaxique des extraits de code

Les points forts d’Hugo

Les limitations d’Hugo

Rien n’est dynamique

Cela paraît évident, mais en utilisant un générateur de site statique, on ne dispose par défaut d’aucune fonctionnalité qui nécessiterait un langage serveur ou une base de données. Ainsi, pas de formulaire de contact ou de commentaires sur les billets de blog.

Dans la pratique, il existe de nombreuses solutions clé-en-main compatibles avec Hugo. Ce sont généralement des petits bouts de de HTML/JavaScript qu’il suffit de copier/coller dans ses pages. Exemples : Typeform pour les formulaires de contact (ou autres), Disqus pour les commentaires. Ces solutions nécessitent souvent de créer des comptes chez ces fournisseurs tiers, et parfois de payer.

Pas de gestion de contenu

Les contenus d’un site Hugo sont des fichiers markdown organisés dans des répertoires. On ré-organise ces fichiers en les renommant ou en les déplaçant physiquement sur son disque dur. Pour un gros volume de contenus, c’est plus fastidieux que de travailler avec une base de données, où l’on peut facilement appliquer des actions en masse au contenu (exemples : rajouter un tag ou changer la valeur d’un champ pour une liste de contenu).

Toujours sur le même thème, il n’y a pas d’interface d’administration dans Hugo. Il serait parfois pratique d’avoir une liste des contenus “brouillon” (= non publiés) ou la liste des contenus taggés “à relire”. Dans la pratique, il existe des solutions. Pour les listes administratives, on peut créer une page sur mesure qui requête tous les contenus répondant à un certain critère. En laissant cette page en draft: true, vous garantissez qu’elle ne sera pas publiée et donc pas accessible à vos utilisateurs.

Pas de contrôle d’accès

Un contenu est soit publié (accessible à tous), soit non publié (accessible uniquement via le serveur de développement). Hugo ne propose pas de solution pour restreindre l’accès de certains contenus à certains utilisateurs.

Pas de petits widgets Angular

Ce n’est pas une limitation d’Hugo, mais d’Angular.

J’aurais adoré avoir certains fragments de page dynamiques dans un site majoritairement statique, idéalement en plaçant un composant Angular en plein milieu de mon HTML (c’est le principe des web components). Cela m’aurait permis d’avoir des petites fonctionnalités dynamiques, comme un moteur de recherche autocomplete, ou de mémoriser ses contenus favoris dans son compte.

Malheureusement, Angular ne fonctionne pas comme ça. Il s’attend à contrôler l’ensemble de la page ou rien. Et devoir créer une application Angular complète pour chaque petit “widget” dynamique que je veux insérer sur la page ne paraît pas approprié. D’autres frameworks comme Vue.js ou React.js paraissent plus appropriés pour une utilisation “partielle”.

comments powered by Disqus