Pourquoi les développeurs ne sont-ils pas plus nombreux à « utiliser la plateforme » ?

Par Nolan Lawson

Depuis des années, les défenseurs des standards du Web, des performances et de l’accessibilité exhortent les développeurs Web à « utiliser la plateforme ». J’ai souvent fait partie de ces défenseurs.

L’argument est simple : pourquoi créer soi-même quelque chose en JavaScript alors que le navigateur peut le faire à votre place ? Quoi que vous créiez, cela aura probablement des performances et une ergonomie inférieures à celles d’une fonctionnalité que le navigateur pourrait vous offrir telle quelle.

Je pense toutefois qu’il vaut la peine d’adopter le point de vue opposé, ne serait-ce que pour comprendre le raisonnement des développeurs « sceptiques vis-à-vis de la plateforme ». Si « utiliser la plateforme » est si évident, alors pourquoi tant de gens semblent-ils avoir besoin d’être convaincus ?

La raison la plus évidente est d’ordre historique : pendant très longtemps, les navigateurs ont couru après l’écosystème qui se développait au-dessus d’eux. Des bibliothèques comme jQuery comblaient des lacunes cruciales pendant que les navigateurs implémentaient des API équivalentes – et même dans ce cas, il fallait parfois attendre que des retardataires comme IE6 soient obsolètes avant de pouvoir réellement les utiliser. Aujourd’hui, la plupart des navigateurs sont « evergreen » (on peut débattre du cas de Safari, même si environ 7 mises à jour par an, ce n’est pas mal), mais jusqu’aux années 2020 environ, les développeurs web devaient composer avec un web résolument hétéroclite. Dans cet environnement, créer ses propres solutions était un choix judicieux.

Une autre raison tient à l’habitude : quand on a l’habitude de chercher des composants React sur npm, c’est vers eux qu’on a tendance à se tourner, quel que soit le problème à résoudre. Si vous recherchez « sticky positioning » sur npm, aucun paquet ne vous dira « utilise simplement CSS position: sticky, espèce d’imbécile ».

Et souvent, même avec une norme solide, les bibliothèques disponibles sur npm comblaient un vide utile entre l’ergonomie du framework et la plateforme sous-jacente. J’ai toujours trouvé intrigant que de nombreux développeurs React préfèrent s’en tenir au JSX et aux idiomes React – les API DOM brutes leur semblaient « dégoûtantes » – mais n’hésitaient pas à utiliser des bibliothèques de bas niveau où les manipulations directes du DOM sont courantes. Par exemple, une bibliothèque de listes virtuelles peut très bien utiliser des API DOM brutes pour des raisons de performances pures, tout en exposant des primitives de plus haut niveau qu’un développeur React novice pourrait mieux appréhender. D’une certaine manière, l’écosystème des composants React a conduit à une division naturelle du travail où ceux disposant d’une plus grande expertise ont encapsulé des API de plateforme peu familières dans un format plus accessible.

Cet effet a également été en partie favorisé par la documentation. De nombreux paquets npm disposent de fichiers README minutieusement détaillés ou de sites web proposant des exemples, des tutoriels et des captures d’écran. Alors qu’avant que MDN ne s’impose comme la référence en matière de documentation web (avec web.dev comme branche de Google davantage tournée vers l’avenir), la documentation relative à la plateforme web était dispersée entre les blogs, StackOverflow et des sites tels que CSS Tricks. Et bon nombre de ces sites se contentaient de vous conseiller d’utiliser une bibliothèque bien connue comme jQuery ou GreenSock !


Mais s’il ne s’agissait que d’une opposition entre les bibliothèques tierces et les API de la plateforme, je ne pense pas que cela suffirait à expliquer pleinement l’antipathie envers le principe « utilisez la plateforme ». Les développeurs paresseux (ou est-ce que je me répète ?) qui veulent simplement une solution toute faite pour n’importe quel problème auquel ils sont confrontés ne se soucient guère de savoir si cette solution provient de npm, du navigateur ou si elle a été copiée depuis un Gist GitHub quelconque. Ils veulent résoudre leur problème et passer à autre chose. Mais il existe une autre source d’opposition à l’« utilisation de la plateforme » que je souhaite explorer.

Pour un certain type de développeur, créer des choses soi-même est tout simplement plus amusant. Et souvent, le code obtenu est plus facile à comprendre, surtout si l’on ne dispose pas d’une connaissance encyclopédique de la plateforme web. Et une fois que vous avez créé quelque chose, il peut se produire une sorte d’« effet IKEA » qui vous pousse à vouloir entretenir et bricoler votre propre code fait maison.

À titre d’exemple, imaginons que vous essayiez de créer une boîte de dialogue modale. Vous comprenez peut-être visuellement comment cela est censé fonctionner : le contenu apparaît à l’écran, mais l’arrière-plan reste visible bien qu’il soit partiellement masqué, et peut-être qu’un clic en dehors de la boîte de dialogue la fait disparaître. Vous pourriez donc vous tourner vers position:absolute et z-index pour positionner correctement la boîte de dialogue – ah, mais l’arrière-plan continue de défiler, vous devez donc désactiver le débordement (overflow) sur le corps… Et puis, si vous vous y connaissez un peu en accessibilité, vous réalisez qu’il faut gérer la touche Échap pour la fermer, créer un « focus trap », redonner le focus à l’élément qui a lancé la boîte de dialogue, et…

Pour de nombreux développeurs, ce que je viens de décrire ressemble à un cauchemar (et à un bon moyen de créer quelque chose qui ne fonctionne qu’à moitié). Mais pour beaucoup d’autres, cela semble amusant ! Pensez à tout ce que vous apprenez en commençant à créer ce projet. Et imaginez comment vous pourriez y apporter votre touche personnelle en ajoutant des animations, des thèmes, un bouton « Fermer » facultatif… Avant même de vous en rendre compte, vous aurez créé une bibliothèque prête à être publiée sur npm. C’est bien plus amusant que de simplement récupérer <dialog> et de s’en contenter – quelle déception !

Et pour beaucoup d’entre nous, avant même que des API comme <dialog> n’existent, c’est ainsi que nous avons appris à connaître la plateforme Web ! Bon nombre de ceux qui prônent aujourd’hui l’« utilisation de la plateforme » ont eux-mêmes été, à une époque, des auteurs de polyfills, de shims et de bibliothèques. Je le sais, car j’en fais moi-même partie ! J’ai passé des années à travailler sur des outils pour IndexedDB, WebSQL et d’autres API de stockage des navigateurs dans le cadre de mon travail sur PouchDB, ce qui m’a finalement permis d’acquérir suffisamment d’assurance pour participer aux réunions sur les normes du W3C et même ouvrir des tickets et envoyer des pull requests concernant la spécification IndexedDB elle-même. Sans la contrainte imposée par une lacune de la plateforme qu’il fallait combler, je ne sais pas si j’aurais trouvé l’intérêt ou la motivation nécessaires pour atteindre ce niveau d’expertise.

Bien sûr, faire les choses soi-même n’est pas toujours une bonne chose en soi. Parfois, cela relève simplement d’une pure ignorance. Sur la plateforme web en particulier, je pense que l’une des raisons pour lesquelles il y a eu une telle prolifération de solutions JavaScript à des problèmes qui auraient pu être mieux résolus par le CSS, par exemple, est que de nombreux développeurs n’ont tout simplement pas pris le temps de comprendre en profondeur comment fonctionne le CSS.

Et pour être honnête, le CSS a toujours été difficile à comprendre ! Ce n’est pas pour rien que le site s’appelle « CSS Tricks ». Des concepts comme le « clear fix », les flottants et l’astuce « min-width: 0 » sont loin d’être intuitifs. Plutôt que d’essayer de comprendre l’algorithme interne du CSS, il est souvent beaucoup plus simple d’imaginer la logique impérative souhaitée, puis de l’exprimer en JavaScript. De plus, pendant des années, le CSS ne disposait pas de moyen simple pour exprimer des modèles courants tels que le clamping de ligne, le redimensionnement des zones de texte, le masquage des barres de défilement, etc. Il est donc tout à fait naturel que les développeurs aient mis en place ces fonctionnalités eux-mêmes à l’aide des outils qu’ils maîtrisaient déjà.

Je ne pense même pas que ce phénomène consistant à « éviter la plateforme » se limite au Web. Il peut s’appliquer à tout développeur travaillant sur une plateforme qu’il ne comprend pas entièrement. Par exemple, dans mon entreprise, nous utilisons ClickHouse pour stocker divers types de données analytiques. À un moment donné, mon collègue et moi étions en désaccord sur la manière de stocker de grandes quantités de données JSON dans une colonne : il avait mis au point un système permettant de les compresser avant le stockage, tandis que j’avais placé les données dans un magasin clé-valeur distinct et n’avais inséré que la clé dans ClickHouse. Il s’est avéré que nous avions tous les deux tort ! ClickHouse compresse automatiquement les données, et comme il s’agit d’un magasin de données en colonnes, on obtient en réalité une meilleure compression sur l’ensemble des lignes si l’on laisse simplement ClickHouse s’en charger. Quant au magasin clé-valeur séparé, il ne s’agissait que d’une version rudimentaire de ce que fait déjà une instruction SELECT en mode colonnes.

Je ne me suis rendu compte de tout cela qu’après avoir pris le temps de lire attentivement la documentation de ClickHouse, puis d’écrire un test de performance pour vérifier mon hypothèse. Au final, j’ai été stupéfait de constater que nous avions construit quelque chose de plus lent et de plus lourd que ce que la plateforme elle-même pouvait nous offrir « clé en main ». Les parallèles avec JavaScript et la plateforme web étaient difficiles à ignorer.

Je suis sûr que si vous êtes développeur sur iOS ou Android, ou si vous développez à partir d’un moteur de jeu, ou encore n’importe quel type de développeur travaillant sur une couche de plateforme, vous avez probablement vécu des expériences similaires. Ce...