Nouveau frontend modulaire

Problème
La structure monolithique héritée du Django n’est pas facile à reproduire d’un point de vue fonctionnel.

En fait, je soutiens auprès de Margot que certaines fonctionnalités sont impossibles à reproduire en reprenant les composantes du site existant (HTML + CSS + JS), car du code issu du backend est sélectivement injecté à divers endroits dans l’application, comme dans la barre latérale dans laquelle des blocs entiers sont générés par Django, selon si on se trouve sur la page d’accueil ou sur la page d’un article/dossier.

De plus, de nombreux morceaux de HTML sont stylés avec des sélecteurs CSS extrêmement précis, il est donc très difficile de les adapter sans passer à nouveau par une sélection profonde (ce qui fragilise les développements futurs, car les styles dépendent en retour d’une imbrication précise entre plusieurs éléments). Par exemple :

/* aside.css */
aside > div[data-module] > section > div:last-child > ul > li > a:hover {
    text-decoration: underline;
}

Pour modifier le style de survol de cette ancre, il faudra chaque fois répéter au moins la chaîne de sélecteurs aside > div[data-module] > section > div:last-child > ul > li > a:hover afin d’avoir le degré de spécificité requis pour modifier ce style ; le style sera d'ailleurs brisé (c-à-d. non appliqué) si la structure HTML change (par exemple, substitution d’un élément <section> pour un <div>. À la longue, ce n’est simplement pas viable.

Bref, un couplage trop fort a été effectué avec Django, et les styles CSS ont été écrits à l’excès pour une structure HTML précise, ce qui rend l’ensemble de la base de code 1) fragile et 2) chronophage à modifier de manière prévisible (il faut sans cesse chercher dans un arbre de sélecteurs multiples au lieu de se fier à une seule classe).

Solution proposée
Massicoter le site en composants qui soient le plus possible autonomes (c’est-à-dire qui ne dépendent pas du style d’un composant parent). Le recours à un framework (bibliothèque) approprié permet de faciliter une telle gestion, en écrivant des styles qui sont automatiquement attribués à chaque composant. Le tree-shaking opéré par ces bibliothèques permet d’ailleurs d’éliminer les styles inutilisés, puisque la structure et le style sont prévisibles, car rationalisés sous forme de composants (ne reposent pas sur une pollution de l’espace global).

Tim a démarré un projet avec Next.js, et moi je propose d’utiliser SvelteKit. Les deux proposent une architecture similaire, quoique je préfère personnellement Svelte (plus proche du HTML « vanille », alors que Next est plus fortement habité par les idiosyncrasies de React). Certains composants Svelte peuvent n’être que du HTML, ce qui facilitera l'éventuelle portabilité (copier-coller dans un autre framework fonctionnera souvent).

Du travail en ce sens a déjà été amorcé sur la branche v3.

Pourquoi réécrire le site
Pour ma part, j’avais tenté de reprendre le HTML/CSS/JS existant, mais pour les raisons mentionnées plus haut, je crois qu’il va simplement falloir repartir de (presque) zéro, en réécrivant « proprement » et en évitant le plus possible la surenchère de fonctionnalités (bloatware). Garder le site simple, quitte à abandonner des fonctionnalités (c’est une revue d’articles scientifiques après tout).