Petit guide du templating client

Les navigateurs ne cessent de s'améliorer et les applications Web mettent de plus en plus à profit le gain de performance des moteurs d'exécution JavaScript ainsi que les nouvelles API offertes par les évolutions des langages côté client. Le requêtage dynamique permis par AJAX fut à lui seul une petite révolution pour les sites Internet, ouvrant la porte à des sites plus interactifs, plus communicants. Permettant de récupérer des données serveur à la demande sans changer de page et sans recharger les éléments communs du site tels que sa structure HTML, ses bibliothèques JavaScript et ses feuilles de style CSS , AJAX fut une composante technologique essentielle pour permettre l'essor du Web moderne représenté par les réseaux sociaux, les webmails et autres « Rich Internet Applications ».

Il se trouve également être à un virage dans l'histoire de l'innovation des technologies Web. En effet, les années 1995 à 2005 ont été marquées par la « bulle Internet » et le « Web 2.0 ». Mais la plupart des innovations de cette décennie résidaient dans les technologies de gestion, de stockage et de génération de contenu employées côté serveur. La première version publique de PHP est apparue en 1995, tandis que JavaEE et ASP.NET sont apparues au début du millénaire pour répondre aux nouveaux usages et besoins des sites de publication et d'échange. L'outillage côté serveur s'étant considérablement amélioré, il s'agissait dès lors de se pencher du côté client.

Emporté par la vague d'AJAX, c'est tout le développement Web front-end qui bénéficia d'un essor depuis. La préparation de la norme HTML5, la révolution mobile et les applications Web multicanaux ont également concouru à cet engouement autour du navigateur. Le rythme de développement de tous les navigateurs s'est accéléré tout comme l'apparition de nouvelles API, bibliothèques et autres outils de développement côté client. De nouveaux modèles de conception suivant cette tendance voient le jour, tels que les Single Page Applications qui sont de plus en plus populaires. Le principe est de ne charger qu'une seule page HTML (souvent statique) depuis le serveur, puis de reposer intégralement sur des requêtes AJAX pour la navigation et l'interaction. L'avantage est que l'on peut réduire le nombre et la taille de ces requêtes, en se contentant des données dans leur expression la plus simple, c'est-à-dire dans un format sérialisé comme JSON ou XML.

Toutes ces nouveautés de plus en plus incontournables ont pour première conséquence de délocaliser toujours plus d'intelligence applicative côté JavaScript. Les développeurs ont alors dû s'adapter et inventer de nouveaux outils pour manipuler plus facilement le Document Object Model (DOM) et interagir avec la page en JavaScript. Vous connaissez probablement tous jQuery, la bibliothèque JavaScript la plus populaire qui s'est fait connaître pour sa fonction sélecteur quasi omnipotente. Aujourd'hui, je vous propose de passer au niveau supérieur en vous présentant tout ce qu'il y a à savoir sur le templating côté client.

Les templates sont des modèles décrivant la manière dont les données sont composées pour former l'aspect final d'un document ou d'une partie d'un document. Dans le cas du Web, ils serviront donc à produire de manière descriptive et intuitive le HTML qui composera vos pages. Historiquement, les outils de templating travaillaient presque tous côté serveur. Certains mêmes étaient des composantes intégrales d'un langage. Ainsi vous connaissez probablement tous les balises <? ?> de PHP ou encore <% %> de JSP.

<h3>Auteur(s) du livre:</h3>
<ul>
<?
    foreach ($authors as $name) {
        echo "<li>$name</li>";
    }
?>
</ul>

<h3>Auteur(s) du livre:</h3>
<ul>
<%
    for (int i = 0; i < authors.length; ++i) {
%>
        <li><%= authors[i] %></li>
<%
    }
%>
</ul>

Tous les outils de templating s'utilisent à peu près de la même façon : on envoie le template d'un côté, les données de l'autre, et il en sort le HTML final de la vue.

Si j'ai parlé d'AJAX en introduction, c'est qu'il est une des raisons principales pour laquelle déplacer ce travail de templating du serveur vers le client peut être une bonne idée. Rien n'empêche de faire une requête AJAX et d'utiliser un templating côté serveur pour générer un fragment de HTML, puis l'envoyer au client pour l'injecter dynamiquement dans la page en JavaScript. Seulement le dynamisme apporté par AJAX est modéré par la durée de la requête, qui comprend la latence réseau et le temps de traitement. De plus, il se peut que certaines actions sur votre site entraînent une modification de la vue sans pour autant que notifier le serveur soit nécessaire. On se retrouve ainsi à devoir faire appel à JavaScript de temps à autre pour modifier la page. Dès lors, pourquoi ne pas franchir le pas et confier tout le templating à JavaScript ?

var data = {
    title : "Good Omens",
    authors : [ "Terry Pratchett", "Neil Gaiman" ]
};

<h2><%= title %></h2>
<h3>Auteur(s) du livre:</h3>
<ul>
<% for(var i=0; i<authors.length; i++) { %>
    <li><%= authors[i] %></li>
<% } %>
</ul>

<h2>Good Omens</h2>
<h3>Auteur(s) du livre:</h3>
<ul>
    <li>Terry Pratchett</li>
    <li>Neil Gaiman</li>
</ul>

Le code ci-dessus est un template EJS (Embedded JavaScript). Il s'agit d'une bibliothèque JavaScript, d'à peine 10 KB, qui s'occupe de lire et d'interpréter les templates tels que celui-ci.

Hé, ce n'est pas très différent du templating serveur.

Hé non ! C'est tout dit la même chose J'ai choisi de vous montrer EJS, car sa syntaxe est volontairement destinée à ne pas brusquer les développeurs habitués à JSP et PHP. La différence majeure réside non pas dans la déclaration des templates, mais dans leur utilisation. Côté serveur, les outils de templating prennent naturellement la main au moment de générer des réponses aux requêtes HTTP reçues. Côté client par contre, vous avez le total contrôle de quand et comment faire appel à votre bibliothèque de templating.

Si vous n'êtes pas encore décidé, voilà un tableau synthétique des avantages et inconvénients du templating côté serveur ou côté client :

Les progrès des navigateurs et des moteurs d'exécution JavaScript tendent à naturellement faire pencher la balance du côté client si l'on réfléchit en termes de performance pure. En effet, même si les templating serveurs resteront au niveau matériel et logiciel plus performants que leur équivalent client, le temps de rendu des templates reste largement inférieur à la latence réseau. Prenons un exemple concret : générer une liste de 10 000 livres et leurs auteurs.

Format HTML attendu :

<ol>
    <li>
        <h2>David Copperfield</h2>
        <h3>Auteur(s) du livre:</h3>
        <ul>
            <li>Charles Dickens</li>
        </ul>
    </li>
    ...
</ol>

Format sérialisé JSON :

{"books":[{"title":"David Copperfield","authors":["CharlesDickens"]},...]}

Admettons que les informations pour un livre occupent en moyenne 120 caractères sous leur forme HTML et 60 sous leur forme JSON. La liste complète de 10 000 livres occupe donc 1,2 Mo en HTML et 600 ko sous forme JSON.

Après benchmark sur un smartphone de gamme moyenne, la bibliothèque de templating JavaScript la plus performante testée (Hogan.js) donne 200 ms de temps de rendu pour la liste de 10 000 éléments. Admettons que l'on dispose d'un serveur puissant ne croulant pas sous la charge et capable de générer cette même liste en deux fois moins de temps, grâce au matériel supérieur et à la précompilation des templates. Cela nous donne donc 100 ms de gagnées en temps de rendu du template en dépit de 600 ko de plus dans la requête. En supposant que ce même smartphone soit dans de bonnes conditions réseau et reçoive la 3 G à un débit moyen de 5 Mb/s, les 600 ko de plus prendront donc environ… une seconde de plus à arriver. Même avec la vitesse des réseaux actuels, le temps de rendu s'avère dix fois plus court que le temps de requête.

Cet exemple est très approximatif et hypothétique, mais il sert juste à rejeter le faux argument exposé au premier abord par les réfractaires du templating client-side selon qui le templating JavaScript n'est pas assez performant par rapport aux solutions serveur.

J'espère à présent vous avoir convaincu que déplacer le templating côté client présente un réel intérêt, et vous dispensera à l'avenir de « code spaghetti » pour modifier vos vues localement.

Quand il s'agit de concevoir un outil de templating, tout le monde n'est pas d'accord sur la part de logique à mettre du côté vue (HTML) et la part de logique à mettre du côté modèle (JavaScript). Certains préfèrent la simplicité en utilisant des syntaxes très permissives voire en écrivant du code JS au sein du HTML. D'autres préfèrent les templates dits « logic-less », afin d'épurer le code des vues et de s'assurer une plus grande proximité entre le modèle de données et ce qui est affiché sur la page.

Question lisibilité, il est difficile de s'accorder. L'un rendra la logique de la vue plus explicite, l'autre mettra le HTML final de la vue en évidence. Il convient donc de choisir selon vos préférences et vos besoins. Néanmoins, la tendance générale est davantage tournée vers les templates logic-less comme le montrent les choix opérés pour Angular et Ember, deux des frameworks JavaScript les plus populaires du moment.

Si on trace un axe allant du plus au moins en quantité de logique côté template, et que l'on y place quelques outils de templating connus, voilà ce que ça donnerait (attention, ce graphe est issu de mon interprétation personnelle des choix faits pour chaque bibliothèque)

Nous n'allons pas tous les passer en revue. J'en ai sélectionné quatre qui représentent bien selon moi les différentes solutions existantes et leurs différences. Pour chacune, nous allons reprendre l'exemple de la liste de livres et comparer les implémentations. Voici les données que nous utiliserons :

var data = [
    {
        title : "David Copperfield",
        authors : [ "Charles Dickens" ]
    },
    {
        title : "Romeo and Juliet",
        authors : [ "William Shakespeare" ]
    },
    {
        title : "Good Omens",
        authors : [ "Terry Pratchett", "Neil Gaiman" ]
    }
];

V-A. La vieille méthode : innerHTML ou jQuery.append▲

var output = "<ol>";

for(var i=0; i < data.length; i++){
    var book = data[i];
    output += "<li><h2>" + book.title + "</h2>"
            + "<h3>Auteur"+(book.authors.length>1 ? "s" : "") + "du livre:</h3>"
            +"<ul>";
    for(var j=0; j< book.authors.length; j++){
        output += "<li>" + book.authors[j] + "</li>";
    }
    output += "</ul>";
}

output+="</ol>";
document.getElementById("result").innerHTML = output;

V-B. DOMjs▲

var template = function(){

    var output = ol();
    for(var i=0; i < data.length; i++){
        var book = data[i];
        var authorsList = ul();

        for(var j=0; j< book.authors.length; j++){
            authorsList( li(book.authors[j]) );
        }

        output(    
            li(
                h2(book.title),
                h3("Auteur"+(book.authors.length>1 ? "s" : "")+"du livre:"),
                authorsList
            )
        );
    }

};

document.getElementById("result").appendChild(domjs.build(template));

V-C. John Resig micro templating▲

<script type="text/html" id="books_template">
    <ol>
        <% for ( var i = 0; i < data.length; i++ ) { %>
        <li>
            <h2><%=data[i].title%></h2>
            <h3>Auteur<% if(data[i].authors.length > 1){%>s<%}%> du livre:</h3>
            <ul>
                <% for ( var j = 0; j < data[i].authors.length; j++ ) { %>
                <li><%=data[i].authors[j]%></li>
                <% } %>
            </ul>
        </li>
        <% } %>
    </ol>
</script>

document.getElementById("result").innerHTML = tmpl("books_template", data);

V-D. mustache▲

<div id="result"></div>
<script id="books_template" type="text/html">
    <ol>
    {{#books}}
        <li>
            <h2>{{title}}</h2>
            <h3>Auteur{{#pluriel}}s{{/pluriel}} du livre:</h3>
            <ul>
            {{#authors}}
                <li>{{.}}</li>
            {{/authors}}
            </ul>
        </li>
  </ol>
</script>

//Data preprocessing
for(var i=0; i < data.length; i++){
    var book = data[i];
    book.pluriel = (book.authors.length > 1);
}
//Template rendering
var html = ich.books_template({ books: data });

//HTML appending
document.getElementById("result").innerHTML = html;

V-E. PURE▲

<div id="result">
    <ol>    
        <li class="books">
            <h2 class="title"></h2>
            <h3 class="authorsLabel"></h3>
            <ul>            
                <li class="authors"></li>
            </ul>
        </li>
    </ol>
</div>

//Data preprocessing
for(var i=0; i < data.length; i++){
    var book = data[i];
    book.authorsLabel = "Auteur" + (book.authors.length > 1 ? "s" : "") + " du livre";
}

$p("#result").render(data);

var directive = {
    'li.books': 'books',
    'h2': 'title',
    'h3': 'authorsLabel',
    'li.authors': 'authors'      
};

$p("#result").render(data, directive);

Avant tout, si j'ai tenu à vous présenter quatre systèmes de templating très différents, c'est pour que vous puissiez vous forger votre propre opinion et choisir en toute connaissance de cause. Chaque approche a ses avantages et ses inconvénients. Mon choix personnel ? J'aime les templates très épurés et je crois beaucoup aux bénéfices du logic less et du templating DOM-based. Mais je n'ai pas trouvé d'outil de templating qui m'apporte totale satisfaction. Alors j'ai comme projet dans les cartons de développer ma propre bibliothèque de templating basée sur les data-attributes : logic-less, DOM-based, non intrusive. La syntaxe de KnockoutJS me plaît beaucoup, dommage que je ne puisse pas utiliser uniquement la partie templating de ce framework MVVM.

Je vous recommande de tester rapidement plusieurs bibliothèques qui vous plaisent au premier abord avant de faire votre choix. Et si vous hésitez encore, il existe ce site : http://garann.github.io/template-chooser/ qui vous permettra de trouver le système de templating qu'il vous faut en répondant à quelques questions.

VII-A. Le data-binding▲

VII-B. Gérer l'internationalisation côté client▲

app.injectHTML = function(container, html){
        var htmlTraduit = html.replace(/{LANG\.([\w\.]+)\}/g, function(match, label){
            if(label in app.lang){
                return app.lang[label];
            } else {
                console.warn("Label "+label+" not found in lang "+app.lang.name);
                return "???";
            }
        });
        $(container).html(html);
    };
    
    app.lang = {
        "name": "FR",
        "accueil.bienvenue": "Bonjour {{username}} !",
        ...
    };

Voilà, vous savez à présent tout du templating client. À présent, vous n'avez plus d'excuses pour écrire du JavaScript interminable et illisible quand il s'agit de générer du HTML. J'espère que cet article vous a été profitable, et je compte sur vous pour venir enrichir le sujet avec vos propres expériences.

Merci à verminevermine ainsi qu'à Bovinovermine pour leur relecture et leurs conseils avisés. Merci à Claude LELOUPClaude LELOUP et Philippe DUVALPhilippe DUVAL pour leur relecture orthographique de qualité.