Le développement excessivement centré sur JavaScript a cassé le Web
(jonoalderson.com)Résumé
Le développement excessivement centré sur JavaScript a cassé le Web
- L’abus des frameworks JS accentue la complexité des sites web
- L’expérience développeur (DX) écrase l’expérience utilisateur (UX)
- Même les tâches simples exigent une architecture excessive
- Les performances, l’accessibilité et la maintenabilité se dégradent
- La solution consiste à rétablir les fonctions essentielles du Web
Introduction
Les dérives d’un Web centré sur le développement
- La plupart des sites web sont inutilement complexes et lents
- Une conception centrée sur JS a fait basculer l’architecture du côté des développeurs plutôt que des utilisateurs
- Même de petites modifications nécessitent désormais des processus de déploiement complexes
Développement
La volonté de ressembler à une app en est la cause
- Depuis les années 2010, avec l’essor des apps mobiles, la demande pour un « web comme une app » a augmenté
- L’adoption de frameworks JS comme Angular a fait exploser la complexité
- Même les contenus simples sont développés comme des systèmes
Une culture qui donne la priorité à l’expérience développeur (DX)
- Les frameworks récents mettent l’accent sur le confort des développeurs
- L’abstraction par composants crée un décalage avec l’UX
- Au lieu de se demander « pourquoi utiliser React pour un blog ? », on privilégie les discussions sur la compatibilité SSR
Une réalité où la complexité est devenue la norme
- Même les tâches simples exigent une architecture à plusieurs couches : build, routage, API, cache, etc.
- À cause de cette stack complexe, les non-développeurs ne peuvent plus modifier le contenu
- Le rythme trop rapide des évolutions techniques rend la maintenance difficile
Les effets néfastes de l’abus de frameworks
- On réimplémente des fonctions web existantes comme SSR, le cache ou les métadonnées
- Les performances baissent et les dépendances se multiplient
- Au final, on en arrive au paradoxe de recréer un CMS avec des frameworks JS
Répétition stérile et coût inutile
- L’adoption puis l’abandon des frameworks se répètent, sans architecture stable
- On se concentre davantage sur la résolution de la complexité interne que sur les vrais problèmes des utilisateurs
- Le content marketing, le SEO et les expérimentations ralentissent, tandis que l’expérience utilisateur se dégrade
Les dégâts du surusage de JS pour les utilisateurs et les marketeurs
- La modification des contenus nécessite l’intervention de développeurs
- Le SEO et la qualité des pages se dégradent
- Pour les utilisateurs, les retards de chargement et les erreurs d’interaction s’accumulent
JS n’est qu’un outil, pas une finalité
- JS est un outil puissant, mais il est excessif pour la plupart des sites web
- Pour du contenu statique, HTML, CSS et un peu de JS suffisent
- Vanilla JS, le rendu côté serveur et un minimum de scripts sont plus efficaces
Concentration du pouvoir et problème structurel
- À cause d’une stack complexe, toutes les tâches dépendent des développeurs
- Dans l’organisation, le pouvoir se concentre structurellement autour des développeurs
- Les choix techniques sont faits selon la commodité des développeurs plutôt qu’en fonction des utilisateurs
Conclusion
La solution consiste à retrouver l’essence du Web
- Il faut des sites web qui chargent vite, sont bien indexés et faciles à maintenir
- Revenir aux fondamentaux — HTML rendu côté serveur, balisage sémantique et JS minimal — est la bonne réponse
- Il faut une approche centrée sur les résultats plutôt que sur la technologie
- Il faut se poser la question : « pourquoi utiliser cette technologie ? »
- Un Web simple et centré sur l’utilisateur apporte à la fois performances, réduction des coûts et flexibilité
23 commentaires
Il suffit de regarder WordPress… cela semble déjà répondre à la question ci-dessus. WordPress a aussi une part de marché bien plus importante, même si c’est lent…
Je pense que les développeurs y adhéreraient davantage s’il y avait des résultats de benchmark à l’appui. Un usage excessif des frameworks rendra certes un site plus lent, mais personnellement j’ai plus souvent vu, du point de vue des transitions entre les pages d’un site, des sites faits en code vanilla être plus lents que des sites utilisant un framework bien optimisé. Bien sûr, s’il s’agit d’un site composé uniquement de données statiques, n’avoir que du HTML + CSS sera peut-être plus rapide, mais je ne sais pas vraiment si les sites basés uniquement sur des données statiques sont encore courants aujourd’hui.
S'il n'y a pas des choses comme React ou Vue,
même si on implémente la même fonctionnalité, il faut écrire du code plus complexe, non ?
Surtout quand on gère des pop-ups, ne serait-ce que passer une prop devient bien plus compliqué en pur JavaScript.
Si même quelque chose d'aussi simple rend le code complexe, alors
les fonctionnalités vraiment complexes deviennent difficiles à implémenter.
C’est une complexité inévitable. Ce n’est plus un simple HTML basé sur des templates comme avant.
Il n’existe pas tant de navigateurs que ça, alors pourquoi y a-t-il autant de frameworks ? Le mieux ne serait-il pas que les entreprises qui gèrent les navigateurs créent un framework optimal et l’entretiennent elles-mêmes ? Jusqu’à quand allons-nous répéter ce cercle vicieux ?
Les philosophies de développement poursuivies sont extrêmement variées, donc.........
Je partage le constat, mais pas la conclusion.
Comme le texte le mentionne aussi, la cause superficielle du phénomène est l’augmentation de la demande pour un « web façon application ».
Hier comme aujourd’hui, le web n’était pas vraiment adapté à la création de « quelque chose qui ressemble à une application », mais à force de bricolages on peut arriver à « faire quelque chose d’assez proche ».
En réalité, le web a été conçu à l’origine comme une plateforme destinée à partager des sortes de « documents », comme des articles scientifiques.
Il suffit de regarder les éléments de base de HTML pour s’en rendre compte.
Puis sont apparues des technologies capables de générer du contenu dynamique, comme CGI, et les navigateurs ont embarqué des langages de script, ce qui a permis d’ajouter du dynamisme au résultat ; c’est ainsi qu’a commencé la sortie du « web en tant que document ».
Le problème, c’est que depuis cette première bifurcation jusqu’à aujourd’hui, le socle du web reste malgré tout un système fondé sur le « document ».
Bien sûr, de nombreuses technologies nouvelles se sont éloignées de cette logique de « document » — WebSocket, WebRTC, WASM, etc. — mais la majorité des sites web continuent encore aujourd’hui d’être développés en s’appuyant sur la plateforme traditionnelle fondée sur le « document ».
Nous devons toujours empiler des balises
divpour dessiner un écran.Voilà pour l’analyse du phénomène ; la question est donc de savoir quelle serait la réponse.
Si l’on imagine les fonctionnalités idéales de la prochaine plateforme sans se soucier du tout du réalisme, cela donnerait quelque chose comme ceci.
(Je ne dis pas que tous les sites devraient fonctionner ainsi, mais seulement ceux qui ont une nature applicative.)
D’abord, le navigateur deviendrait une sorte de lanceur d’applications.
Une fois téléchargée, une application devrait pouvoir s’exécuter hors ligne.
Et l’application serait implémentée dans d’autres langages, en sortant du triptyque HTML/CSS/JS.
Dans ce processus, le navigateur pourrait fournir une sorte de framework, un peu comme Android.
La manière de communiquer avec le serveur pourrait elle aussi s’éloigner des requêtes web traditionnelles pour adopter un autre paradigme.
Pour les communications nécessitant du temps réel, on pourrait conserver les communications TCP telles quelles,
et on pourrait aussi créer et utiliser une forme de communication RPC plus simple, qui n’emploierait pas le protocole HTTP.
Je ne comprends pas très bien ce que vous voulez dire dans la dernière partie, quand vous parlez d'une plateforme idéale.
Au final, on parle de l'époque où il fallait télécharger un programme natif et y utiliser ActiveX.
Au fond, le problème tient au fait qu’on force la création d’un web de type application à l’intérieur du protocole HTTP, qui repose à la base sur des « documents » web.
L’idée était donc que, si des fonctions de niveau applicatif sont nécessaires pour résoudre cela, pourquoi ne pas créer un nouveau protocole et un nouveau framework pensés pour les applications ?
De la même manière que, sur smartphone, ce ne sont pas des programmes purement natifs qui s’exécutent mais des applications fonctionnant dans une sorte de sandbox, la structure consisterait ici à les faire tourner au niveau du navigateur.
Bien sûr, il faudrait d’abord garantir l’ouverture et la standardisation pour éviter que cela ne tourne à l’ActiveX.
Même pour un web de type application, je pense qu’il faut viser quelque chose de proche de la conclusion présentée. Si on utilise beaucoup de JavaScript, cela devient lourd côté client.
En pratique, ce n’est pas comme s’il n’existait aucun framework permettant de l’implémenter ainsi. Rien qu’avec Next.js, si l’on réduit au minimum l’usage des composants client en ne les utilisant que lorsque c’est nécessaire, c’est globalement possible. Et dans l’écosystème Rails mentionné par un autre intervenant, Hotwire (https://hotwired.dev/) propose justement un ensemble de frameworks prenant en charge un web de type application (Turbo, Stimulus, etc.) qui permet d’approcher de très près la conclusion avancée par l’auteur.
Je partage l’idée de fond de cet article, mais certains passages me laissent tout de même perplexe.
Par exemple, un site web promotionnel pour un service précis exploité par notre entreprise conserve justement le même type de simplicité que cet article encense. Heureusement, ce site est composé en grande majorité d’éléments assez statiques. Le code frontend, comme le HTML et le CSS, a été écrit à la main sans aucun framework, et le JS se limite plus ou moins à jQuery et Google Analytics. Les annonces et le forum, entre autres, sont implémentés en AJAX avec jQuery, mais je ne pense pas que cela relève d’un niveau de complexité déraisonnable ou excessif. À mes yeux, c’est à peu près le niveau qu’on pouvait déjà construire avec jQuery quand j’ai débuté dans le développement web. À ma connaissance, ce site existe depuis l’époque d’Internet Explorer, donc je ne l’ai pas créé moi-même, mais je ne le trouve pas mauvais du tout.
Mais il est aussi géré avec le contrôle de version Git et un pipeline CI/CD, avec un serveur de staging séparé du serveur de production. Quand une Pull Request est fusionnée dans la branche Main, le pipeline déploie automatiquement sur le serveur de staging le résultat généré par le bundler, puis, après vérification du serveur de staging par le responsable et approbation finale du déploiement, cela est à nouveau déployé sur le serveur de production. Par le passé, on se contentait d’écraser directement les fichiers sources sur le serveur de production via FTP, mais après le transfert de cette activité à notre équipe, nous avons procédé à ce changement.
Est-ce vraiment une complexité irrationnelle ? Autrefois, modifier la balise de titre de ce site revenait simplement à ouvrir directement le fichier HTML du serveur de production avec AcroEdit prenant en charge la connexion FTP (oui, les personnes qui avaient rédigé directement le HTML du site utilisaient toujours cela), modifier une seule ligne, enregistrer, et tout était terminé. Il est donc probable que ces personnes le perçoivent ainsi.
Mais, pour ma part, je pense que ce niveau de complexité supplémentaire était tout à fait acceptable. Toutes les tâches ne se résument pas à modifier une simple balise de titre. Et le fait de pouvoir supprimer sans hésitation d’anciens bouts de code auparavant laissés en commentaires partout, puisqu’on peut toujours les restaurer, la possibilité d’un suivi transparent des changements et d’un rollback, ou encore le fait de pouvoir ajouter, si nécessaire, quelques optimisations de base via le bundler, sont à mes yeux de vrais avantages. On pourrait aussi dire que l’ajout d’un serveur de staging pour prévisualiser avant déploiement en environnement réel constitue une forme de complexité, mais je pense que c’était nécessaire.
Moi aussi, je suis très mécontent de la manière dont la structure interne du code de divers sites web est devenue excessivement complexe et lourde. L’application Outlook de Windows est aujourd’hui basée sur une web app, et récemment elle est devenue particulièrement plus lourde. Il suffit de rédiger le corps d’un mail à l’écran ou même de sélectionner tout le texte pour que cela rame, voire affiche « page sans réponse ». Je me suis demandé ce qui se passait, puis j’ai ouvert les outils de développement dans Outlook Web et j’ai été stupéfait. Après avoir vidé le cache et rechargé la page, des requêtes continuaient encore à apparaître une minute plus tard. En vérifiant dans le navigateur, j’ai vu que plusieurs gigaoctets de données étaient stockés rien que pour des sites liés à MS Office.
Cela dit, cet article mélange plusieurs sujets ; je suis d’accord avec certaines parties, mais beaucoup moins avec d’autres. Pour ce qui est du HTML sémantique et de l’accessibilité, j’ai plutôt l’impression que le passé était bien pire. Et l’idée selon laquelle l’amélioration de l’expérience développeur dégraderait l’expérience utilisateur ne me parle pas du tout, même si c’est peut-être parce que je ne suis pas développeur frontend web. Quant à l’affirmation selon laquelle tout le pouvoir et tout le contrôle se seraient concentrés chez les développeurs, elle me paraît franchement absurde. En entreprise, le pouvoir n’est-il pas du côté de la direction ? Ou bien la structure des entreprises en Occident est-elle à ce point différente de celle de la Corée ?
Comme toujours, je suis tout à fait d’accord sur le fait que l’équilibre et la modération, ainsi que la simplicité et le pragmatisme, sont des valeurs importantes et doivent être prioritaires dans la prise de décision. En revanche, cet article soutient que le fait de « traiter tous les sites web comme des produits logiciels » relèverait presque entièrement de la responsabilité des développeurs, et je pense que c’est précisément ce point qui brouille le problème de fond. Et les passages qui semblent idéaliser le « bon vieux temps » d’avant, quand rien n’était vraiment structuré, mériteraient au contraire d’être critiqués.
N’est-ce pas une tout autre histoire que celle dont vous parlez ?
Quelle partie vous semble raconter quelque chose de totalement différent ?
Au fond, je pense que ce que cet article critique, c’est une complexité excessive et l’inflation qui en découle. Je ne pense pas que mon commentaire soit complètement hors sujet simplement parce que je n’y ai pas parlé de JavaScript. D’une certaine manière, c’est une critique d’un aspect secondaire. Et comme je l’ai mentionné dès le début dans mon commentaire, je partage moi aussi la conscience du thème fondamental de l’article d’origine.
Je pense que vous avez mal compris l’intention de l’article original.
Vous dites :
"...Ici, nous avons mis en place la gestion de versions avec Git ainsi qu’un pipeline CI/CD, et nous avons séparé le serveur de staging du serveur de production. Lorsqu’une Pull Request est fusionnée dans la branche main, le pipeline déploie automatiquement sur le serveur de staging l’artefact généré par le bundler. Après vérification du serveur de staging par la personne responsable, si le déploiement est approuvé définitivement, il est alors redéployé sur le serveur de production. Par le passé, nous écrasions simplement directement les fichiers source sur le serveur de production via FTP, mais après que ce travail a été transféré à notre équipe, nous avons procédé à ce changement.
Est-ce vraiment une complexité irrationnelle ?"
Mais cela me semble assez peu lié au sujet de l’article. La manière dont vous gérez le déploiement et l’exploitation, à ce niveau-là, et ce que défend cet article me paraissent très différents.
L’intention du texte original n’est pas simplement de critiquer les frameworks JS devenus trop complexes.
Pour plus de commodité, je vais citer la traduction coréenne en lien ci-dessus.
> Aujourd’hui, il faut jusqu’à 4 ingénieurs, 3 frameworks et un pipeline CI/CD rien que pour changer un simple titre. Publier une page web est devenu absurdement complexe.
> Peu à peu, le web est ainsi devenu quelque chose qu’il faut compiler avant de le publier. Non pas parce que les utilisateurs en ont besoin, mais parce que les développeurs voulaient avoir l’impression d’être modernes.
> Tout a été optimisé pour les développeurs, et c’est devenu hostile à tous les autres.
> Nous ne nous contentons plus de tolérer la complexité : nous la considérons comme normale. Nous partons du principe que chaque site a besoin d’une étape de build, d’un bundler, d’une stratégie d’hydration, d’une couche de routing, d’une couche API, d’un design system et d’une logique sophistiquée d’invalidation de cache. Nous construisons en microservices, nous hébergeons sur des réseaux edge et nous déployons des pipelines pour livrer du contenu pourtant simple.
> Nous sommes en train de recréer les fonctionnalités de plateformes comme WordPress, mais avec un résultat 10 fois plus lourd et bien moins utilisable. Pire encore, chaque nouvelle couche introduit de nouveaux bugs, de nouveaux problèmes de compatibilité et une nouvelle charge cognitive. Nous en sommes maintenant à maintenir une logique d’hydration, une stratégie de cache et un pipeline de build simplement pour mettre en ligne une page d’accueil.
> Les campagnes marketing prennent du retard parce que la bibliothèque de composants n’est pas assez flexible. Les tests A/B sont annulés parce que la couche d’analytics n’est pas compatible avec la stratégie d’hydration. Les mises à jour de contenu doivent parfois attendre des jours que le build se lance. Les ajustements SEO les plus basiques se perdent dans le backlog.
> Les marketeurs ne peuvent ni mettre à jour un texte ni lancer une expérimentation sans créer un ticket. Ils ne peuvent pas prévisualiser le contenu, tester une mise en page ni publier une page. Chaque changement doit passer par des développeurs, un pipeline, des validations et une reconstruction.
> Les marketeurs, les éditeurs de contenu, les responsables SEO, les designers : tous sont exclus du processus. Car désormais, même les tâches simples exigent une aisance technique. Si vous voulez modifier une balise title, on vous dira d’en parler à un ingénieur ; si vous voulez publier une campagne, on vous dira d’ouvrir un ticket et d’attendre deux sprints.
> Tout passe par l’équipe de développement. Cela signifie que c’est elle qui décide de ce qui est important, de ce qui est déployé et de ce qui est repoussé indéfiniment dans les priorités. Et plus elle ajoute de la complexité, plus elle devient indispensable.
Contrairement à la culture de développement coréenne, où le travail descend de la direction vers les planificateurs puis vers les développeurs, en Occident il n’existe pas vraiment d’équivalent au concept coréen de « planificateur », et les développeurs participent activement à la planification produit, entre autres. Les PM occidentaux, par exemple, ne correspondent pas parfaitement aux planificateurs coréens, tout comme une cover letter ne correspond pas exactement à une lettre d’auto-présentation coréenne. Bien sûr, pour les jeux, où la dimension de projet créatif est forte et où le fun et la jouabilité sont essentiels, l’Occident est lui aussi plus horizontal que l’Asie, mais le travail y descend tout de même du directeur vers les développeurs.
Je vois, il y a donc cette différence.
Mais je ne pense pas que cela soit vraiment lié au contenu ci-dessus.
Utilisez Rails, soyez heureux
Je suis d’accord avec l’idée principale de cet article. Ces derniers temps, on abuse tellement de JS que même avec un i9-9900k, il arrive souvent que des sites rament. Ce n’est pas une configuration très claire, ni vraiment pour le jeu ni vraiment pour le travail, mais dans la réalité, il existe énormément d’ordinateurs de bureau encore moins puissants que ça.
C’est pour ça que j’aime Astro et Hotwire, des frameworks dont la philosophie est de n’utiliser JS que lorsque c’est absolument nécessaire, par exemple pour les parties interactives ou la navigation interactive entre pages. J’aime aussi le server-side rendering, c’est-à-dire l’idée de faire le rendu côté serveur. En revanche, je déteste profondément le CSR (y compris quand seuls les méta-tags sont rendus côté serveur et que tout le reste est géré en CSR). Je considère que cela revient à faire porter au client un travail qui devrait être fait par le serveur. Personnellement, je pense que l’approche SPA traditionnelle utilisant le CSR devrait être réservée aux cas où le frontend s’exécute localement dans des applications comme Electron. Bien sûr, lorsqu’on charge le frontend depuis le serveur, il faut utiliser le SSR.
Voici un résumé des réactions en commentaires au billet, classées en 5 catégories :
1. Accord total et soutien
Caractéristiques principales : accord total avec les arguments du texte et reconnaissance des problèmes d’une stack JS complexe.
Exemples d’avis :
2. Inquiétude face à l’abus des frameworks
Caractéristiques principales : critique de l’usage excessif de frameworks comme React ou Angular, avec l’idée que des technologies plus simples suffisent.
Exemples d’avis :
3. Accord partiel + prise en compte de la réalité
Caractéristiques principales : adhésion au fond de l’argument, tout en reconnaissant que la complexité peut être inévitable ou nécessaire dans certaines situations.
Exemples d’avis :
4. Critique de la culture de développement et de la structure du secteur
Caractéristiques principales : l’excès de frameworks n’est pas seulement un problème technique, mais aussi le produit des mécanismes de recrutement, de la culture et du marketing.
Exemples d’avis :
5. Critique ou opposition
Caractéristiques principales : désaccord avec la prémisse de l’article ou critique de son caractère unilatéral.
Exemples d’avis :
Oh, le fait de l’avoir divisé par types le rend agréable à consulter et très pratique.
Je partage le constat du texte original sur le problème de la « complexité excessive du web ». En revanche, j’ai du mal à accepter un diagnostic qui en attribue la cause uniquement à la culture des développeurs ou à l’abus de frameworks. Aujourd’hui, la complexité du web est en grande partie l’ombre portée des fonctionnalités et des exigences de sécurité imposées inévitablement par les modèles économiques. Laisser de côté cet aspect ne peut conduire qu’à une analyse incomplète.
Le web n’est plus une « galerie gratuite ». À l’exception des sites publics, la plupart des services web actuels ont pour objectif de générer des revenus. Dès lors, la question centrale dans le choix technique ne devrait pas être « ce code est-il pur ? », mais « cette technologie permet-elle à notre activité de réussir ? ».
Vu sous cet angle, le « web de contenu léger » idéalisé par le texte original se heurte au mur des exigences économiques du monde réel. Par exemple, une activité qui vend du contenu ne peut pas fonctionner avec de simples pages statiques. Pour gérer les abonnements payants et les paiements, il faut une logique à états comme l’authentification utilisateur, la vérification du statut d’abonnement et la gestion des autorisations ; pour protéger le contenu, une couche de sécurité comme la validation en temps réel des tokens afin d’empêcher la copie illégale ou les accès non autorisés est indispensable. De plus, pour améliorer l’expérience utilisateur et le taux de conversion via la personnalisation et les tests A/B, un traitement dynamique des données est également nécessaire.
Tout cela relève du domaine de l’« application sophistiquée », et les frameworks sont des outils pragmatiques pour le mettre en œuvre.
Bien sûr, toute complexité ne peut pas être justifiée. Nous devons distinguer deux types de complexité.
Complexité inévitable : c’est la complexité, au ROI clair, qui apparaît pour implémenter des fonctionnalités métier (authentification, paiement, personnalisation, etc.). C’est un coût qu’il faut accepter.
Complexité accidentelle : c’est la complexité inutile créée par la commodité du développement ou par une abstraction technique excessive. C’est une dette technique et un gaspillage qu’il faut mesurer en continu et éliminer.
Les services qui réussissent distinguent ces deux dimensions pour construire une architecture réaliste. Autrement dit, ils allègent au maximum la couche de front où le marketing et le SEO sont essentiels, tout en s’appuyant sur des frameworks dans les zones internes qui nécessitent des transactions critiques ou des fonctions de personnalisation, afin d’assurer la fiabilité : une stratégie hybride qui permet de concilier rapidité et richesse fonctionnelle.
Le texte original se concentre sur la culture des frameworks comme seule cause de la dégradation de l’expérience utilisateur, en écartant les « exigences inévitables engendrées par le modèle économique ». Parler du développement web sans cet élément, c’est un peu comme parler uniquement du fait de servir au client un « plat rapide et savoureux » à sa table, tout en faisant comme si la cuisine complexe où ce plat est préparé et la caisse où l’on encaisse n’existaient pas.
Parce que le web est lourd, on ne peut pas simplement abandonner les frameworks sans réfléchir. À mon sens, le vrai sujet est de savoir comment implémenter le plus efficacement possible, au coût minimal, les fonctionnalités exigées par l’activité afin de délivrer de la valeur à l’utilisateur.
Voici la traduction coréenne ci-dessous.
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…