Vanillapp

Les frameworks front-end (React, Vue, Angular pour ne citer que les plus connus) sont efficaces. De façon générale, on peut dire qu'ils apportent une structure, une robustesse, une bonne productivité et une scalabilité.

• Organisation et maintenabilité du code : ils imposent une structure (composants, état, cycle de vie...) qui normalise le code, le rend plus clair, plus facile à faire évoluer.
• Gestion de l'état : ils proposent des outils (props, stores...) pour synchroniser plusieurs partie de l'UI.
• Performance, DOM virtuel : seuls les éléments qui changent sont rendus à nouveau.
• Écosystème : librairies prêtes à l'emploi, composants réutilisables, outils (linting, tests, build, optimisation...).
• Expérience développeur et productivité : rechargement à chaud, typage grâce à TypeScript, intégration facile avec des API, routage, internationalisation, formulaires complexes...
• Communauté et recrutement : connaître un framework est souvent requis en emploi, la communauté des utilisateurs et utilisatrices est très étendue.

Ces frameworks proposent de réaliser la couche front-end en Javascript, en particulier en méthode AJAX. C'est-à-dire qu'ils sont pertinents dans un contexte de consommation d'API de données et non pas dans celui d'un serveur qui renvoie du HTML. La vue est donc gérée par le navigateur (le client exécute du Javascript) et pas par le serveur (celui-ci renvoie seulement la donnée JSON, XML...).

Or, on peut constater que rien n'est impossible en Javascript dit vanilla, c'est-à-dire sans utiliser de frameworks puisque ces derniers sont fondés sur Javascript.

• Organisation et maintenabilité du code : un framework ne garantit pas la qualité car programmer consiste à exprimer les exigences de conception quelle que soit l'implémentation choisie. Ici, il s'agit donc plutôt de la question de conventions (programmation, gestion de projet...).
• Gestion de l'état : design pattern Observer, modules avec paramètres de configuration... rien qui ne nécessite de frameworks.
• Performance, DOM virtuel : l'API native Web Component permet l'encapsulation, le réemploi, et peut produire des composants plus rapides et légers qu'un DOM virtuel supplémentaire à gérer en mémoire.
• Écosystème : plus de librairies signifie plus de dépendances, donc plus de risques de sécurité, de compatibilité, de poids... ce qui peut augmenter rapidement la dette technique. En vanilla, moins de dépendances, donc plus de contrôle.
• Expérience développeur et productivité : Javascript est le fondement des frameworks et n'est pas utilisé que par eux (back-end avec Node.js, desktop avec Electron...), la communauté de ses développeurs est donc aussi voire plus étendue que celle des frameworks. Mais on peut admettre qu'un projet ambitieux implique la rapidité et les outils intégrés d'un framework.
• Communauté et recrutement : beaucoup de personnes qui programment ne sont formées qu'aux frameworks et ne connaissent pas vraiment Javascript. Le framework est gage de rapidité, de normalisation... mais développe la dépendance à un environnement et entretient l'ignorance. Connaître le langage de programmation permet de s'adapter quand un framework disparaît.

Les deux inconvénients majeurs à la programmation en Javascript vanilla sont le temps de développement (dont conception, tests) et la connaissance requise (dont recherches avec la communauté des développeurs et développeuses).

Par conséquent, le choix est dirigé non pas par la technique mais par des besoins organisationnels, commerciaux, financiers (confort d'équipe, recrutement, délais, time-to-market...).

C'est dans cet axe de réflexion (critique ouverte à la discussion) que je me suis lancé le défi de réaliser un site web qui propose l'UX d'un framework du marché... mais en Javascript vanilla.

Deux orientations étaient possibles :

1. créer un serveur qui retourne des ressources (fichiers), qui renvoie toujours la page d'accueil dans le cas contraire, tout le reste (routes, historique...) étant géré en Web Component côté front-end,
2. créer un serveur qui retourne des ressources, qui renvoie du HTML lorsqu'une route de navigation est demandée, tout le reste étant géré côté front-end sans nécessiter Web Component.

Pourquoi deux orientations ? Le critère distinctif entre ces solutions est le SEO (Search Engine Optimisation). En effet, pour indexer une page, le robot d'indexation (crawler, spider, comme Google Bot par exemple) doit parcourir du contenu (avec ou sans micro-données de type Schema), donc il faut que le serveur retourne les données utiles. Or, dans une application web monopage (simple page application), comment gérer le SEO lorsqu'il y a plusieurs routes conduisant à du contenu à chaque fois différent alors que le seul contenu reçu en HTML est celui de la page d'accueil ? Eh bien, par exemple en testant l'entité qui effectue la requête : si c'est un robot d'indexation, alors renvoyer le contenu au format correspondant ; sinon, renvoyer une ressource. Problème : cela multiplie le contenu ; ou bien il faut réaliser une architecture qui sépare la donnée de son destinataire, ce qui ajoute un niveau de complexité inattendu mais intéressant. Par conséquent, si on veut rester simple, il faut penser une autre architecture : renvoyer du HTML par défaut (pour un robot d'indexation ou non) et les ressources associées, puis laisser le front-end gérer les prochaines requêtes en AJAX (ce qui autorise des transitions, la gestion de l'historique...). Du point de vue de l'expérience utilisateur, aucune différence entre les deux approches.

À ces deux orientations s'ajoute une exigence qui découle de la réflexion initiale mais cette fois portée sur le back-end : comment réaliser le serveur sans recourir à un framework, voire sans dépendances ? Pour répondre à cette question, j'ai choisi de coder le serveur en Node.js vanilla là aussi. En plus de cela, la sécurité doit être assurée (en-têtes, règles...).

Le résultat attendu est ce que j'appelle une vanillapp.

Les deux orientations ont conduit chacune à un projet spécifique mais dans les deux cas les serveurs partagent une approche commune.

Le premier est SmoothModule (dépôt GitHub). Retours d'expérience :

1. Web Component permet la gestion de modules de façon confortable tout en restant dans un seul langage de programmation (JS) : soit on code le shadow DOM à l'aide de l'API Element, élément par élément (recommandation de sécurité émanant de l'ANSSI), soit on le code à partir d'une source HTML écrite dans un template (pas de problème de sécurité tant qu'aucune donnée n'est injectée),
2. La gestion des styles CSS est plus complexe que prévue du fait du cloisonnement des composants et de la CSP (Content Security Policy) qui interdit l'usage des styles et scripts dits inline... mais rien ici d'insurmontable : il s'agit de charger un nouveau fichier de styles ou bien de sélectionner une classe CSS à partir des styles déjà chargés,
3. je n'ai pas abordé la question du SEO (la complexité inattendue mais intéressante dont je parlais plus haut) simplement pour garder le cap que je me suis donné. Il faudra néanmoins que je transforme cette exigence en nouvelle fonctionnalité.

Le second est EasyFront (dépôt GitHub). Cette solution est celle utilisée pour réaliser le présent site que vous consultez ! Retours d'expérience :

1. puisque le serveur retourne des pages HTML, alors le programme back-end peut inclure un générateur automatique de sitemaps (dans l'autre projet, ce serait plus délicat car il faudrait identifier dans un composant ce qui relève du contenu indexable, à moins d'envisager la complexité inattendue intéressante),
2. pour la même raison, Web Component n'est plus nécessaire mais on pourrait utiliser cette API pour des questions de flexibilité ; les scripts restent néanmoins des modules,
3. pour la même raison, chaque page peut appeler librement de nouveaux styles, de nouveaux scripts.

Créer une vanillapp prend sans doute plus de temps qu'utiliser un framework (a fortiori si le projet est complexe). Mais cela représente aussi une formidable opportunité pour monter en compétences (conception, réalisation, sécurité). Une vanillapp satisfait pleinement l'objectif de qualité, de maîtrise, de contrôle du contenu (pas de dépendances dont il faudrait vérifier l'intégrité, la qualité, l'évolution...). Elle démontre une autonomie, une indépendance, le développeur ou la développeuse n'étant pas réduit ou réduite à une consommation de solutions du marché. Enfin, la vanillapp représente l'exigence de réaliser un produit selon l'artisanat logiciel.