Générateurs de sites statiques & tutoriel Nanoc

Après une présentation générale de ce que sont les générateurs de sites statiques, nous réaliserons un vrai site avec Nanoc en suivant notre tutoriel pas-à-pas.

Qu'est-ce que c'est ?

Un générateur de site statique est une application qui crée des pages web en fonction de certains paramètres : structure, modèles, comportements, conditions, etc.

Ce que l'on recherche avec de telles applications est la possibilité d'établir des règles et des automatismes concernant la création des pages, et ne plus avoir à se soucier que du contenu.

Update: Nanoc a beaucoup changé depuis cet article. N'oubliez pas de consulter la doc pour comprendre les différences.

Un générateur de site statique est une application capable de transformer de nombreux formats vers du HTML, de gérer des modèles de pages (“layouts”), de suivre une certaine logique (si tel type de page alors tel type de navigation, par exemple), de proposer des méthodes de tri (catégories, mots-clés, etc) et de présentation des contenus, etc.

Avec une telle application, on crée une sorte de “machine” qui acccepte vos nouveaux contenus et les insère automatiquement, suivant certaines règles, dans votre site, tout habillés et configurés comme vous le souhaitez.

C'est un système de publication de contenus pour le web.

A quoi ça sert ?

Un générateur de site statique n’est pas un gestionnaire de contenu (Content Management System), car c’est vous qui gérez votre contenu : l’application a pour sa part le rôle de gestionnaire des tâches ingrates.

L’usage le plus répandu d’un générateur de site statique est le *blog*.

En effet, avec une telle app, vous n’avez qu’à rédiger vos articles : c’est l’application qui se charge de les mettre en page, de créer l’index, de mettre à jour les archives, créer au besoin une nouvelle entrée dans les catégories, de mettre la date à côté du titre, etc.

Mais ces applications ne sont pas faites que pour créer des blogs, elles sont également très utiles pour créer un site de documentation, des vitrines commerciales, galeries d’images ou de films, wikis, présentations, site pour un évènement, critiques de film, etc, bref : toutes les situations où le contenu sera la priorité à long terme.

C’est particulièrement utile parcequ'on bénéficie du principe des layout, ces modèles de page qui « entoureront » ensuite vos contenus automatiquement.

Pourquoi pas un site dynamique de type Wordpress ?

Un site statique, ce sont de simples fichiers HTML.

Des fichiers texte.

Les serveurs web sont capables de servir ces fichiers à une vitesse fulgurante.1

Un site dynamique, c'est une base de données dans laquelle le serveur va piocher les éléments et construire les pages pour vous les servir à chaque fois que vous les demandez. C'est le principe.

Avec un site statique, les pages sont déjà construites et sont servies en quelques millisecondes à peine.

A titre d'exemple, un de mes sites Wordpress qui se chargeait en 4s en moyenne à partir d'un serveur pas très vif se charge désormais, en version statique, en moins d’une seconde2, sur le même serveur et avec la même quantité de contenu… plus des images format Retina !

Pas de base de données = pas de piratage de la base de données.3

Même croulant sous la charge de multiples visiteurs, un serveur correct sera toujours capable de délivrer des pages web statiques, alors qu’il aura du mal à gérer les requêtes SQL de la base de données dans ce genre de situation.

Vous générez le site localement avant de le pousser sur le serveur, donc vous pouvez tout voir et contrôler à l'avance.

Si vous faites une erreur, une faute de frappe, un lien mal renseigné, vous pouvez le tester et le corriger avant la mise en ligne sans risquer de casser la base de données ou d'autres éléments du site.

Vos pages web sont des fichiers que vous pouvez manipuler et consulter, transporter, partager, modifier, etc, même en dehors de la structure d'accueil de votre site.

Mieux, les contenus ne sont pas mélangés au PHP ni au HTML mais séparés (souvent dans des fichiers texte au format Markdown), ce qui rend leur usage et conservation encore plus simple.

Vous pouvez gérer le versioning de votre site avec Git (ou autre), ce qui est impossible avec une base de données.

Ca rend également la sauvegarde plus aisée.

Pourquoi pas coder en html directement ?

Coder une page web de A à Z manuellement est tout à fait possible et même rapide grâce à des frameworks tels Zurb Foundation, Twitter Bootstrap, Gumby 2, etc.

C’est envisageable pour une simple « landing page », un CV, carte de visite, etc, à la condition que le contenu ne change pas (ou très peu) et ne soit pas complexe.

Dès que le contenu est amené à changer plus ou moins souvent, que le site contient plusieurs pages, que les contenus dépassent les quelques lignes de texte, coder un site à la main devient rapidement une tâche insurmontable.

Le moindre changement devant être répercuté sur plusieurs pages entraîne des modifications en chaîne.

Si vous avez une galerie de photos et que vous décidez d’en rajouter de nouvelles, il vous faut retourner dans le code, modifier la mise en page, ajouter les liens, uploader les images au bon format, chasser les bugs, remettre les fichiers sur le serveur, modifier la page d’accueil au besoin pour refléter les nouvelles entrées, changer les vignettes dans le sommaire, et peut-être bien répéter tout ça pour les autres pages du site qui contiennent ces éléments… un calvaire, sans compter que c’est une incroyable source d’erreurs et la porte ouverte au syndrome de « copy pasta ».4

Si toutes vos pages qui présentent vos contenus sont en HTML, vous vous retrouvez avec votre texte mélangé aux tags structurels, ce qui le rend peu lisible et difficile à modifier. Si vous utilisez PHP c’est encore pire : personnellement lire du code de Wordpress me déchire les yeux.

Avec un générateur de site, vous pouvez écrire vos contenus en simple texte, en Markdown, LateX, etc, et ensuite les transformer en HTML automatiquement.

Avec un générateur de site, vous créez vos modèles de page une seule fois, et ensuite vous n’avez plus qu’à créer vos contenus : ils seront insérés dans le site habillés du modèle que vous leur aurez attribué.

Principes de base

Ligne de commande

La plupart de ces générateurs fonctionnent de la même façon : ils créent un squelette de site et ensuite, si on active différents modules et fonctions, créent les pages et les liens correspondant.

Dans Mac OSX et GNU/Linux, ça passe par une commande que l’on tape dans le Terminal (une console, xterm, etc).

Terminal

Il y a généralement peu de commandes à mémoriser :

Pour ceux qui ne maîtrisent pas la ligne de commande, n’ayez crainte, ça vient vite, et de nombreux tutoriels sur le web vous aideront à vous familiariser avec l’outil.

Choix du langage

Un générateur de sites fonctionnera souvent avec un ensemble de règles qui lui permettront de router les pages, créer des éléments en fonction de la nature d’un fichier, etc.

Ces règles sont édictées dans le langage de programmation qu’a choisi le développeur de l’application.

Il sera donc necessaire de choisir un générateur que l’on manipulera avec un langage avec lequel on est à l’aise.

Les deux principaux langages que vous retrouverez sont Ruby et Python.

Mais il y en a également en JavaScript (avec Node.js), Perl, Haskell, Bash/Zsh, Java…

Côté formatage et layout5, on retrouvera encore plus de prétendants : ERB, Mustache, Liquid, Handlebars, Haml, etc.

Pour la rédaction des contenus il y a également de nombreuses possibilités, trop nombreuses pour les énumérer ici, cependant on notera qu’une d’entre elles est quasiment devenue un standard : Markdown.6

Fonctions/plugins

Un site qui n’est pas dynamique, c’est-à-dire qui n’est pas généré au moment de la requête de la page, n’est pas forcément pour autant un site plat et inactif : les mots sont trompeurs !

Parmi les nombreuses fonctions que l’on pourra intégrer dans un site statique grâce à un générateur, on retrouvera par exemple :

- NANOC -

Maintenant que nous avons fait un petit tour de la situation, nous allons nous pencher sur un de mes générateurs favoris : Nanoc.

Caractéristiques

Nanoc est écrit et fonctionne avec Ruby.

J’aime particulièrement Ruby parceque sa syntaxe est proche du langage naturel, ses principes de fonctionnement sont clairs et il est amusant à utiliser.

Nanoc est léger, rapide, robuste, et particulièrement bien maintenu par son auteur, Denis Defreyne.

Comme souvent avec ce qui épouse la philosophie Ruby, Nanoc est simple dans son organisation des éléments tout en étant très riche en fonctions.

Précision

On pourrait croire qu'il soit necessaire de savoir programmer avec Ruby pour utiliser Nanoc : absolument pas !

On peut utiliser Nanoc tel quel sans rien connaitre du tout à ce langage de programmation.

Cependant, évidemment, connaître Ruby est un plus : cela permet d'éditer les filtres, les modules, de personnaliser les comportements, etc.

Pourquoi choisir Nanoc

Un des principaux avantages de Nanoc est de pouvoir accepter un grand nombre de langages pour construire vos pages web.

On peut, grâce aux filtres, écrire en Markdown ou RestructuredText, on peut utiliser Erb, Mustache, Handlebars dans ses layouts, Sass ou Less pour le Css, etc.

La gestion des routes en Ruby est relativement facile après avoir étudié quelques exemples.

On observe toujours le même type de logique : si telle URL alors faire ceci, si tel type de fichier alors faire cela, etc.

Nanoc est très rapide : même un site de plusieurs centaines de pages lourdes d’éléments sera généré en à peine quelques secondes.

Un petit site est généralement créé par Nanoc en quelques centièmes de seconde…

Install et config

tl;dr7

gem install nanoc

Mais je vous conseille ceci pour prendre les devants :

rvm use 1.9.3
sudo gem update --system
gem install nanoc systemu w3c_validators nokogiri adsf kramdown rsync compass maruku

Ce sont tous des gems (applications en ruby) que Nanoc pourra utiliser dans ses filtres ou ses fonctions.

Et bien sûr, comme toujours, utiliser git pour le contrôle de versions du projet.

Usage

mkdir dossier && cd dossier
nanoc create-site monsite
cd monsite
rvm use --default 1.9.3
nanoc compile
nanoc view &
nanoc watch &
open http://localhost:3000
subl .

Explication des commandes précédentes, ligne par ligne :

Je conseille également d’installer l’extension Livereload pour votre navigateur, ou d’utiliser guard.

On peut aussi ajouter Compass (bien éditer config.rb comme on le verra plus loin) ou mettre le tout dans Codekit (en adaptant les règles de destination pour les dossiers).

Deploy

Le déploiement utilise rsync.

Inutile de manipuler un logiciel FTP, une seule commande suffira pour tout mettre en ligne.

Il suffit de configurer vos identifiants et URL de serveur dans nanoc.yaml (anciennement config.yaml) :

# rsync deployment
deploy:
    public:
        kind: rsync
        dst: "id@server.com:path"
    test:
        kind: rsync
        dst: "id@test-server.com:path"

puis faire :

nanoc deploy --target test
nanoc deploy --target public

Sass

Utiliser Sass dans sa syntaxe SCSS avec Nanoc n'est pas facile après une installation de base, il faut procéder à une modification.

Heureusement, Daniel Hofstetter a fait un résumé :

D'abord :

compass init

puis dans les fichiers :

1. config.rb

output_style = "compact"
line_comments = false
http_path = "/"
sass_dir = "content/css"
css_dir = "output/css"
images_dir = "output/img"
javascripts_dir = "output/js"

2. Rules

2.1

require 'compass'
Compass.add_project_configuration 'config.rb'

2.2

compile '/css/*' do
    filter :sass, Compass.sass_engine_options.merge(:syntax => :scss)
end

2.3

route '/css/*' do
    unless item.identifier.start_with?('/css/_')
        item.identifier.gsub(/\/$/, '') + '.css'
    end
end

puis @import 'compass’; comme d'habitude dans le fichier scss principal.

Astuces

Si l'on veut un filtre sur une seule url :

compile /mapage do
    filter :maruku
    layout default
end

Pour bénéficier de la fonction render qui permet de faire des « partials » (include comme en PHP) il faut déclarer le helper dans lib/ :

include Nanoc::Helpers::Rendering

Puis dans un layout, pour intégrer par exemple le fichier head.html qui se trouve dans le dossier layouts :

<%= render 'head' %>

Exemple tiré du site de Nanoc : un fichier en-tête commun mais avec un titre personnalisé pour chaque page.

Dans le layout de head :

<h1><%= @title %></h1>

Dans le fichier qui sera rendu par le layout :

<%= render 'head', :title => 'Foo' %>

Le résultat :

<h1>Foo</h1>

Il suffira désormais d’ajouter un titre dans l’en-tête de toute page pour qu’il soit rendu par le layout :

---
title: Mon titre
description: Nous sommes sur la page d’accueil
categories: [truc, machin, chose]
layout: default
---

Le layout « default » importe le layout « head » et crée la page complète avec son propre titre.

Ecrire de la documentation

Nanoc très bon pour créer rapidement une poignée de layouts puis écrire ou récupérer toute la doc en Markdown.

En quelques étapes Nanoc vous permet de créer un site basé sur du contenu.

Pour notre tutoriel, nous aurions pu utiliser la pagination comme pour un blog, mais ce serait inadapté à un contenu documentaliste.

Quand les URL changent car vous avez modifié des chapitres par exemple, il y a un problème de bookmarks qui ne correspondent plus à rien. C’est-à-dire que si votre page se nomme « Page 7 » et qu’un internaute la place dans ses favoris, il sera bien embêté en arrivant sur cette page alors que vous aurez ajouté du nouveau contenu… Tout sera décalé.

Il vaut mieux faire script pour générer une table des matières, ou trouver plugin qui le fait pour vous.

Le script analyse par exemple les titres dans votre document Markdown et crée un lien vers chacun d’entre eux. Un peu de Javascript et vous insérez cette TOC dans votre page d’index ou au début du chapitre concerné.

- TUTORIEL NANOC -

Nous voici arrivés au tutoriel pour créer un site avec Nanoc.

nvALT-guide

Nous allons transformer un article de blog assez long sur nvALT en un mini-site façon documentation, comme un manuel d’utilisation ou un fascicule d’étudiant.

Ce guide en français sur nvALT sera plus facile à consulter (liens de titres, catégories) et il pourra plus facilement être mis-à-jour et enrichi, sur Github par exemple.

Nous allons suivre la création de ce site pas à pas.

Installation & configuration

Comme vu plus haut :

1. installer Node.js, RubyGems puis Nanoc et ses dépendances

rvm use 1.9.3
gem install nanoc
gem install systemu w3c_validators nokogiri adsf kramdown rsync compass maruku

2. générer le site

nanoc create-site monsite
cd monsite

3. initialiser Compass

compass init

4. compiler le site une première fois

nanoc compile

5. changer la structure et créer les règles pour Sass/Markdown

6. ajouter les helpers et/ou plugins necessaires

Dans le dossier lib :

include Nanoc::Helpers::Rendering
include Nanoc::Helpers::LinkTo
include Nanoc::Helpers::Blogging

Git

git init
touch .gitignore
subl .gitignore

ajoutez dans .gitignore :

.DS_Store
.sass-cache
Rules
output
tmp
crash.log

puis faites :

git add .
git commit -m 'init'

Créez un repo sur Github puis :

git remote add origin git@github.com:USERNAME/REPONAME.git
git pull origin master
git push -u origin master

Puis le moment venu on enverra tout sur le serveur web avec cette commande :

nanoc compile && nanoc deploy --target public

Comme rsync est très rapide et incrémental, tout est immédiatement disponible en ligne.

On pourra se faire un alias dans bash ou zsh pour aller encore plus vite :

alias nanodep = ‘cd mondossier && nanoc compile && nanoc deploy --target public && cd -’

Voir plus haut les réglages pour le déploiement sur votre serveur avec rsync ainsi que pour la structure des règles dans Nanoc.

Organisation

Il faut maintenant décider du la structure du site.

Nous allons partir sur :

L'URL du site sera donc : http://mondomaine.com/nvalt-guide

Pour Sass, j’aime bien m’organiser avec un jeu de fichiers comme ceci :

On créera au fur et à mesure du tutoriel ces fichiers qui seront importés dans screen.scss, lui-même transformé vers screen.css par le filtre de nanoc.

On aura donc par exemple les URL suivantes :

http://domaine.ext/nvalt-guide/
http://domaine.ext/nvalt-guide/install
http://domaine.ext/nvalt-guide/metatags
http://domaine.ext/nvalt-guide/automatismes
http://domaine.ext/nvalt-guide/synchronisation
http://domaine.ext/nvalt-guide/previsualisation
http://domaine.ext/nvalt-guide/export

index.html

On le renomme en index.md puis dans Rules on remplace erb par kramdown :

compile '*' do
    if item.binary?
        # don’t filter binary items
    else
        filter :kramdown
        layout 'default'
    end
end

Au lieu d’utiliser ERB, on va maintenant pouvoir écrire nos pages web en Markdown, car nous venons d’indiquer à Nanoc que chaque fichier qui n’est pas un binaire doit être compilé avec le filtre kramdown et le layout default.

Si l’on désirait par exemple écrire certains types de pages en Textile, alors il suffirait d’indiquer le type de fichier en argument à la fonction compile au lieu d’une étoile qui représente tous les types de fichier, et de remplacer l’appel au filtre kramdown par un appel au filtre textile que vous auriez alors installé sur votre machine.

Default layout & styles

J'importe normalize.css et crée des styles de base.

Dans default.html je mets en place les basiques en m'inspirant de html5 boilerplate.

Je sépare la sidebar et la place dans un fichier à part. A la place, dans default.html, j'insère :

<%= render 'sidebar' %>

On ajoute des règles pour Javascript dans Rules :

compile '/js/*/' do
    nil
end
route '/js/*/' do
    item.identifier.chop + ".js"
end

La première règle signifie que les fichiers .js ne doivent pas être compilés.

La deuxième règle signifie que tout fichier se trouvant dans le répertoire /js/ sera copié dans le dossier du site avec une extension .js.

Ces règles doivent impérativement être placées *avant** les autres règles plus génériques, car dans Nanoc c’est la précédence qui est prioritaire.*

J’installe les dernières versions de modernizr (recommandé) et jquery (optionnel) avec Bower :

mkdir content/js
cd tmp
bower install html5-boilerplate
cp components/html5-boilerplate/js/* ../content/js/
cd ..

A ce stade, notre dossier contient ceci :

├── Rules
├── config.rb
├── content
│   ├── css
│   │   ├── _normalize.scss
│   │   └── screen.scss
│   ├── img
│   ├── index.md
│   └── js
│       ├── main.js
│       ├── plugins.js
│       └── vendor
│           ├── jquery.min.js
│           └── modernizr.min.js
├── layouts
│   ├── default.html
│   └── sidebar.html
├── lib
│   └── default.rb
├── nanoc.yaml
├── output
│   ├── css
│   │   └── screen.css
│   ├── img
│   ├── index.html
│   └── js
│       ├── main.js
│       ├── plugins.js
│       └── vendor
│           ├── jquery.js
│           └── modernizr.js

Pages

On crée notre première page, qui représente en fait le premier chapitre.

Normalement on utilise la commande :

nanoc create-item nomdelapage

mais cela crée une page html que je dois ensuite renommer en .md car je préfère rédiger les contenus en Markdown.

Nous pouvons à la place créer nos pages directement dans le répertoire :

touch content/page.md

mais il faut alors rajouter les meta informations à la main.

Libre à vous de vous préparer des alias, fonctions et/ou snippets TextExpander pour vous faciliter la vie, ou de simplement utiliser la commande de nanoc et ensuite renommer le fichier.

Si vous importez des données ou souhaitez créer un grand nombre de fichiers d'un coup, un script avec une boucle peut être utile.

De toute façon, le contenu de ces méta informations (titre, description, catégories, etc) est grandement susceptible de changer par la suite.

Dans le cas de notre guide nvALT, la page que nous venons de créer se nomme “avantages”.

Nous créons un lien vers cette page dans le titre correspondant dans la sidebar et vérifions que tout marche bien.

A ce stade, notre page d'accueil ressemble à ceci :

nvALT-guide : page d'accueil avec Nanoc

C’est le thème par défaut fourni par Nanoc, léger et fonctionnel.

Extrait du Markdown qui compose cette page :

Extrait Markdown

Dans mon cas je connais déjà le plan du guide nvALT, donc je crée directement le reste des pages : je fais glisser tous les fichiers .md dans content et je déclare les liens correspondants dans la sidebar.

Pour vous, si vous suivez le tutoriel, vous pouvez ajouter vos propres pages en Markdown ou autre, copier-coller vos contenus dans des pages vierges, etc.

N’oubliez pas qu’avec notre système, le contenu est séparé du contenant, vous travaillez sur les documents d’une part, et sur le site d’autre part.

En quelques minutes à peine, voilà un site complet à mettre sur un serveur !

├── approfondir
│   └── index.html
├── apps
│   └── index.html
├── astuces
│   └── index.html
├── avantages
│   └── index.html
├── bases
│   └── index.html
├── concentration
│   └── index.html
├── css
│   └── screen.css
├── img
├── index.html
├── installation
│   └── index.html
├── js
│   ├── main.js
│   ├── plugins.js
│   └── vendor
│       ├── jquery.js
│       └── modernizr.js
├── liens
│   └── index.html
├── merci
│   └── index.html
├── organisation
│   └── index.html
├── recherche
│   └── index.html
├── tags
│   └── index.html
├── tri
│   └── index.html
└── visuel
    └── index.html

Je n'ai créé ni codé aucun fichier HTML, c'est *nanoc** qui a tout fait quand je lui ai donné les fichiers Markdown : il a tout emballé dans des pages grâce au fichier layout.html*.

Personnalisation

Je sépare head et foot dans les layout pour y voir plus clair.

Dans le cas d’un site plus grand, il sera conseillé de tout séparer : menus, logos, modules de la sidebar, sections, etc.

Cela permettra de modifier facilement tout le site en n’éditant que quelques lignes dans un seul fichier.

Maintenant, grâce à Compass je passe les pages web en mode border-box grâce à un mixin dans le body :

@include box-sizing(border-box);

et je donne quelques max-width à mes éléments.

Comme ça j’oublie tout de suite les problèmes de marge, de padding ou de dépassement des éléments.

Bien sûr c’est une solution de rapidité : si vous construisez un site pour un client, il faudra vérifier que vos pages soient compatibles avec un grand nombre de navigateurs, y compris de vieilles versions d’Internet Explorer, et certaines n’acceptent pas le mode « border-sizing ».

De manière générale il faut toujours utiliser la dernière version d’un navigateur moderne, tel Google Chrome, Mozilla Firefox ou Apple Safari… mais nous ne pouvons pas forcer la main à nos utilisateurs, n’est-ce pas ?

Nous allons maintenant améliorer la présentation avec un peu de SCSS : meilleure typographie, choix des couleurs, etc.

Après quelques tatonnements, on arrive à quelque chose de présentable :

nvALT-guide avec Nanoc : page d'accueil

nvALT-guide avec Nanoc : chapitre 2

nvALT-guide avec Nanoc : chapitre 8

Autres générateurs de sites statiques

Ce n'est pas ce qui manque… mais nombre d'entre eux sont laissés à l'abandon par leurs auteurs, ou utilisent des technologies obsolètes ou au contraire avant-gardistes.

On en dénombre quand même une bonne vingtaine qui soient encore d'actualité, dont à mon avis les plus intéressants en ce moment en plus de Nanoc : Bonsai blog, Middleman, DocPad, Jekyll/Octopress

Une liste beaucoup plus fournie vous attend chez Nanoc en bas de page.

Equivalents avec interface graphique

Les barbus vous diront que nous utilisons déjà une interface graphique, puisque nous voyons à l'écran les lettres que nous tapons sur le clavier… ;)

Nous disions donc, des équivalents à Nanoc avec interface à cliquer… je n'en connais pas.

Il y a cependant des plateformes qui s'approchent de la philosophie suivie par Nanoc et ses confrères, et qui présentent plus ou moins d'originalité et de fonctions différentes, certaines utilisant même PHP ou une base de données mais en local, et autres sortes de trouvailles : Blue CMS, TiddlyWiki, Punch CMS, PieCrust CMS, PageGen, Stacey App, toto, Mynt, Nikola, Nesta CMS, Anchor CMS, etc.

Sources & téléchargements

Le texte en Markdown de ce tutoriel est disponible dans le repository de mon blog sur GitHub - version téléchargeable.

Vous en faites ce que bon vous semble, à condition de citer la source si vous l'utilisez.

Le site nvALT-guide que nous avons créé avec le tutoriel est disponible dans son propre repository sur GitHub. Clonez-le : git clone git@github.com:galaakk/nvALT-guide.git et compilez-le (vous savez faire, maintenant).

Idéalement, vous en profitez pour trouver des erreurs ou ajouter du contenu. :)

Remerciements

Merci à Nanoc, Sayanee, les gens sur Stack Exchange, les gens sur Google Groups et à toute la communauté du monde Open Source en général.


  1. une partie des arguments exposés ici proviennent de la très bonne documentation en anglais sur le site de Nanoc 

  2. évidemment tout n'est pas comparable, comme on le verra plus tard dans le tutoriel 

  3. Wordpress attaqué 

  4. si malgré tout vous avez besoin de coder des pages à la main, alors faites-vous aider par CodeKit, Hammer ou Mixture, des logiciels qui vous offriront des fonctions, entre autres, d'include et de pré-processing. 

  5. templating langages 

  6. standard de part son adoption généralisée et sa qualité intrinsèque, et non pas par son format, au contraire sujet à de multiples extensions et versions fortement fragmentées, même si souvent similaires 

  7. une partie des éléments dans cette section proviennent directement du site de Nanoc 

Auteur: Eric Dejonckheere