3.2Moteurs de templates & service de fichiers statiques
Une application web fait souvent deux choses côté serveur : générer des pages HTML dynamiques et servir des fichiers statiques (CSS, images, JavaScript client). Commençons par le service de fichiers statiques. Une application web a des ressources fixes à livrer au navigateur : feuilles de style CSS, images, fichiers JavaScript côté client, polices, etc. Express les sert très simplement avec le middleware natif express.static() : app.use(express.static('public')) sert tous les fichiers du dossier public/ directement (une requête vers /style.css renvoie public/style.css). C'est le moyen standard de livrer les assets d'un site. En pratique, on organise un dossier (souvent public/) pour tous les fichiers statiques.
Pour générer du HTML dynamique côté serveur, on utilise des moteurs de templates (aussi appelés « moteurs de vues »). Le principe : au lieu d'écrire du HTML fixe, on écrit des templates (gabarits) — du HTML avec des emplacements et une logique (insérer des variables, boucler sur une liste, afficher conditionnellement) — et le moteur GÉNÈRE le HTML final en injectant les données. Exemple : une page qui affiche une liste de produits — le template boucle sur les produits et génère le HTML pour chacun. Express supporte de nombreux moteurs ; les plus courants : EJS (Embedded JavaScript, syntaxe proche du HTML avec du JS dans des balises <% %> — simple et populaire), Handlebars/hbs (syntaxe avec {{ }}, « logic-less » — épurée), Pug (syntaxe indentée très concise, sans balises HTML explicites). On configure le moteur (app.set('view engine', 'ejs')), on place les templates dans un dossier views/, et on rend une vue avec res.render('page', { données }) — Express génère le HTML en passant les données au template. Ce modèle s'appelle le SSR (Server-Side Rendering, rendu côté serveur) : le serveur construit le HTML complet et l'envoie au navigateur. Une remarque importante sur les architectures : le SSR (serveur qui génère les pages HTML) est une approche, largement utilisée et pertinente (sites de contenu, applications classiques, SEO). Mais beaucoup d'applications modernes adoptent une autre architecture : le serveur Node expose une API REST (qui renvoie du JSON, section 4-1) consommée par un front-end séparé (React, Vue, Angular… qui génèrent l'interface côté navigateur). Dans ce cas, Node ne fait PAS de rendu HTML — il sert des données JSON, et le front s'occupe de l'affichage. Les deux approches sont valables selon le projet : SSR (Node génère le HTML) pour des sites classiques ; API + front séparé (Node sert du JSON) pour les applications interactives modernes (SPA). Ce guide couvre les deux, mais l'accent des niveaux suivants (API, auth) va vers l'approche API/JSON, très répandue. Comprendre les templates et le service statique reste utile (beaucoup d'applications les emploient, et c'est formateur), tout en sachant qu'une grande part du développement Node moderne consiste à bâtir des API JSON pour des fronts séparés.
Vocabulaire de la section
- Fichiers statiques
- Ressources fixes livrées au navigateur (CSS, images, JS client, polices) ; servies simplement avec le middleware express.static('public').
- Moteur de templates (vues)
- Outil générant du HTML dynamique à partir de templates (HTML + logique : variables, boucles, conditions) et de données ; EJS, Handlebars, Pug…
- res.render()
- Méthode Express rendant une vue : res.render('page', { données }) génère le HTML en injectant les données dans le template (dossier views/).
- SSR (Server-Side Rendering)
- Le serveur génère le HTML complet et l'envoie au navigateur ; approche des sites classiques (contenu, SEO).
- API + front séparé (SPA)
- Alternative moderne : Node expose une API REST (JSON) consommée par un front séparé (React/Vue/Angular) qui gère l'affichage côté navigateur.
SSR (templates) ou API + front séparé : quelle différence ?
En pratique — Servir des fichiers et générer du HTML
- Servez des fichiers statiques avec `app.use(express.static('public'))` : placez un CSS et une image dans public/ et vérifiez qu'ils sont accessibles.
- Configurez un moteur de templates (ex. EJS : `app.set('view engine', 'ejs')`) et placez des templates dans views/.
- Rendez une vue avec des données : `res.render('page', { titre: '...', items: [...] })` ; dans le template, insérez les variables et bouclez sur une liste.
- Comparez : rendez la même donnée en JSON (`res.json(data)`, approche API) pour percevoir la différence SSR vs API + front séparé.
Points clés à retenir
- SERVICE STATIQUE : `app.use(express.static('public'))` sert les ressources fixes (CSS, images, JS client) directement — le moyen standard de livrer les assets.
- MOTEURS DE TEMPLATES (EJS, Handlebars, Pug) : générer du HTML dynamique à partir de templates (HTML + variables/boucles/conditions) et de données, via `res.render('vue', {données})`.
- SSR (Server-Side Rendering) : le serveur génère le HTML complet — approche des sites classiques (contenu, SEO).
- Alternative moderne très répandue : Node expose une API REST (JSON) consommée par un FRONT SÉPARÉ (React/Vue/Angular). Les niveaux suivants penchent vers l'approche API/JSON.
Questions fréquentes
SSR (templates) ou API + front séparé : quelle architecture choisir pour mon projet ?
C'est une décision d'architecture importante, et les deux approches sont valables selon le PROJET — voici comment décider en comprenant leurs forces respectives. Le SSR (Server-Side Rendering) — le serveur Node génère le HTML complet (avec des templates comme EJS) et l'envoie au navigateur. Convient bien quand : (1) Sites de CONTENU : blogs, sites vitrines, sites d'actualité, documentation, e-commerce classique — des sites où le contenu prime et où chaque page est essentiellement du HTML à afficher. (2) SEO important : le HTML est généré côté serveur et livré tout prêt, donc parfaitement indexable par les moteurs de recherche (historiquement, le contenu généré côté client était moins bien indexé — même si cela s'est amélioré). Pour un site dont le référencement est crucial, le SSR est un atout. (3) Chargement initial rapide : le navigateur reçoit du HTML prêt à afficher (pas besoin d'attendre le chargement et l'exécution d'un gros JavaScript avant de voir le contenu). (4) Simplicité pour des sites peu interactifs : si l'application n'est pas très « app-like » (peu d'interactions dynamiques complexes), le SSR est plus simple (pas besoin d'un framework front lourd). L'API + front séparé (SPA — Single Page Application) — Node expose une API REST (JSON), et un front séparé (React, Vue, Angular) génère l'interface côté navigateur en consommant cette API. Convient bien quand : (1) Applications INTERACTIVES / « app-like » : tableaux de bord, applications de gestion, réseaux sociaux, outils complexes — des interfaces très dynamiques, avec beaucoup d'interactions, de mises à jour sans rechargement de page. Le front (React/Vue) excelle pour ces interfaces riches. (2) Expérience fluide : une SPA charge une fois, puis met à jour l'interface dynamiquement (sans rechargement complet) — expérience proche d'une application native. (3) Séparation front/back : l'API et le front sont des projets séparés, potentiellement avec des équipes différentes (spécialistes front, spécialistes back), et l'API peut servir PLUSIEURS clients (le site web, une application mobile, d'autres services) — le même back-end JSON alimente tout. (4) Écosystème front moderne : si vous/votre équipe utilisez React/Vue/Angular, l'approche API est naturelle. Les considérations : (1) le SSR est plus SIMPLE pour des sites classiques et meilleur pour le SEO « out of the box » ; (2) l'API + SPA est plus adaptée aux applications interactives et à la réutilisation du back par plusieurs clients (web + mobile), mais ajoute de la complexité (deux projets, gestion de l'état côté front, SEO à gérer autrement). (3) Il existe des approches HYBRIDES modernes (frameworks comme Next.js, Nuxt qui font du SSR AVEC React/Vue — le meilleur des deux mondes : rendu serveur pour le SEO/chargement + interactivité front) — un domaine en évolution. Pour votre apprentissage de Node : (1) l'accent des applications Node modernes est très souvent sur l'API REST (JSON) consommée par un front séparé — c'est pourquoi les niveaux suivants de ce guide (API REST, authentification par JWT, temps réel) vont dans cette direction, la plus répandue pour le développement d'applications. (2) Mais comprendre les templates/SSR reste utile (beaucoup de projets les emploient, c'est formateur, et l'hybride SSR moderne est important). (3) Le côté Node (le back-end) est similaire dans les deux cas quant aux compétences de base (routage, middlewares, bases de données, sécurité) — c'est surtout ce que Node RENVOIE qui change (HTML rendu vs JSON). En résumé : SSR (templates) pour les sites de contenu et le SEO ; API + front séparé (SPA) pour les applications interactives et la réutilisation du back par plusieurs clients ; approches hybrides modernes (Next.js/Nuxt) pour combiner. Choisissez selon la nature du projet (site de contenu vs application interactive), l'importance du SEO, et l'écosystème/l'équipe. Pour apprendre Node à fond, concentrez-vous sur la construction d'API REST solides (l'approche dominante et la compétence back-end centrale) — ce que font les niveaux suivants — tout en connaissant l'existence et l'usage du SSR. Votre valeur de développeur Node est surtout dans le back-end (API, données, sécurité, performance), applicable aux deux architectures.
Le rendu côté serveur est-il dépassé face aux frameworks front comme React ?
Non, le rendu côté serveur n'est ni dépassé ni obsolète — il connaît même un RENOUVEAU avec les frameworks modernes — mais son usage a évolué, et comprendre cette évolution éclaire le paysage actuel du développement web. L'histoire en bref : (1) À l'origine, le web était surtout du SSR : le serveur générait des pages HTML (PHP, Rails, et côté Node les templates comme EJS). Le serveur faisait tout, le navigateur affichait. (2) Puis sont arrivées les SPA (React, Vue, Angular) : le serveur envoie une « coquille » + du JavaScript, et le front génère l'interface DANS le navigateur en consommant une API. Cela a permis des applications très interactives et fluides — d'où l'engouement, au point qu'on a pu croire le SSR « dépassé ». (3) Mais les SPA pures ont révélé des limites : SEO plus difficile (le contenu est généré par JS côté client, moins bien indexé historiquement), chargement initial plus lent (il faut télécharger et exécuter un gros JavaScript avant de voir quoi que ce soit), complexité accrue. (4) D'où un RETOUR et une RÉINVENTION du rendu côté serveur, sous des formes modernes : des frameworks comme Next.js (pour React) et Nuxt (pour Vue) font du SSR (ou du rendu statique, ou hybride) TOUT EN utilisant React/Vue pour l'interactivité. On combine ainsi les avantages : le HTML est rendu côté serveur (bon SEO, chargement initial rapide) ET l'application reste interactive côté client (l'expérience SPA). C'est aujourd'hui une approche très prisée. Donc, loin d'être dépassé, le rendu serveur est central dans les architectures web modernes — mais sous des formes évoluées (SSR combiné aux frameworks front, rendu statique, hybride). Où en est-on concrètement : (1) Le SSR « classique » avec des templates Node (EJS, Handlebars) reste PERTINENT et UTILISÉ pour de nombreux sites (contenu, sites classiques, back-offices, projets où sa simplicité convient). Il n'est pas mort — beaucoup d'applications l'emploient très bien. (2) Le SSR MODERNE (Next.js, Nuxt) est en plein essor pour les applications qui veulent le meilleur des deux mondes (SEO + interactivité). (3) Les SPA pures (front + API JSON, sans SSR) restent parfaites pour les applications très interactives où le SEO importe peu (outils internes, tableaux de bord, applications derrière authentification). (4) Le choix dépend du projet (comme détaillé dans la FAQ précédente). Ce que cela signifie pour vous (développeur Node) : (1) Le côté NODE/BACK-END que vous apprenez (API REST, bases de données, authentification, sécurité, performance) est PERTINENT quelle que soit l'architecture front — que le front soit une SPA, du SSR classique, ou du Next.js, il a besoin d'un back-end solide (une API, une base, de la sécurité). Votre compétence back-end est le socle, applicable partout. (2) Comprendre le SSR classique (templates) reste utile et formateur (et directement applicable à de nombreux projets). (3) Savoir que le rendu serveur MODERNE (Next.js/Nuxt) existe et gagne en importance est utile pour le paysage — mais ces frameworks relèvent plutôt du domaine front/full-stack (React/Vue avec SSR) que du back-end Node pur. (4) L'approche API REST + front séparé (que privilégient les niveaux suivants) est très répandue et une compétence back-end centrale — apprendre à bâtir de bonnes API JSON vous sert dans TOUTES ces architectures (une SPA consomme une API, Next.js peut consommer/exposer des API, etc.). En résumé : le rendu côté serveur n'est pas dépassé — il a évolué. Le SSR classique (templates Node) reste pertinent pour beaucoup de sites ; le SSR moderne (Next.js/Nuxt combinant serveur et React/Vue) est en plein essor ; les SPA pures gardent leur place. Ne voyez pas cela comme « SSR vs React » (une opposition dépassée) mais comme un ÉVENTAIL d'architectures adaptées à différents besoins. Pour vous, l'essentiel est de maîtriser le BACK-END Node (API, données, sécurité) — le socle commun à toutes ces approches — tout en comprenant le paysage front (SSR, SPA, hybride) pour situer votre travail. Le développement web est en évolution constante ; les concepts fondamentaux (HTTP, API, données, sécurité, et les principes de rendu) restent, les architectures se combinent et se réinventent. Rester curieux du paysage tout en solidifiant les fondamentaux est la bonne posture.