Construire pour le Web, construire sur le Web, construire avec le Web

Une traduction de Build for the Web, Build on the Web, Build with the Web avec autorisation de l’auteur, Harry Roberts.

Si vous voulez construire pour le Web, construisez sur le Web et construisez avec le Web.

Si je ne devais donner qu’un seul conseil aux entreprises, ce serait d’itérer rapidement sur une plateforme qui évolue lentement.

Au cours de la seule année dernière, j’ai vu deux clients complètement différents, dans deux secteurs complètement différents, consacrer des mois et des mois à des mises à niveau de leurs environnement de travail. Collectivement, ils ont dépensé des dizaines, voire des centaines de milliers de dollars pour réécrire des projets entiers dans le seul but de maintenir les mêmes fonctionnalités qu’avec l’itération précédente. Il ne s’agit pas d’un travail utile ou productif, mais de temps perdu à se contenter de rester à la même place.

C’est d’une certaine façon un emprisonnent dans un écosystème, où ajouter la moindre amélioration de performance même la plus triviale devient impossible vu que les framework offusquent, et parfois même empêchent de regarder sous le capot. Le pire ? Vous devrez tout recommencer dans 18 mois ! Vous êtes contraint par les choix technologiques, et vous héritez de toute une équipe de développement qui doit être payée un ou deux trimestres tous les deux ou trois ans, juste pour faire du sur-place.

Elles font des itérations lentes sur une plateforme qui évolue rapidement.

Le plus triste dans tout cela, c’est qu’il s’agit d’anciens clients qui ont dû me réembaucher parce que les « mises à jour » s’accompagnaient de graves régressions de la vitesse du site. Même si c’est bon pour les affaires, je déteste faire le même travail avec le même client plus d’une fois. Après tout, on ne devrait jamais avoir à appeler deux fois le dératiseur.

Le Web en tant que plateforme est une valeur sûre. Par conception il n’a pas de version. C’est l’engagement que le Web prend à votre égard : profitez-en.

1. Adopter progressivement les fonctionnalités de la plate-forme Web. Pour paraphraser mon ami Ryan Townsend : les clients ne veulent pas des transitions de page fluides – ils veulent un site Web qui fonctionne. Ne faites pas de votre site une Single Page Application unique juste pour ne pas avoir à renvoyer une en-tête et un pied de page.

2. Adoptez l’amélioration progressive pour créer des applications rapides et fiables qui s’adaptent au contexte de vos clients. L’intérêt d’opter pour les fonctionnalités de la plateforme Web au fur et à mesure qu’elles sont disponibles est que votre site devient adaptatif. La même base de code s’adapte à son environnement, en jouant sur ses points forts, plutôt que d’essayer de construire et d’expédier votre propre environnement à partir de zéro. Rencontrez vos utilisateurs là où ils se trouvent.

3. Écrivez un code qui s’appuie sur le navigateur, et non qui s’en éloigne. En utilisant l’amélioration progressive, vous pouvez opter pour des fonctionnalités natives du navigateur qui sont généralement plus rapides, plus accessibles, plus sûres et, ce qui est peut-être le plus important pour l’entreprise, maintenues par quelqu’un d’autre.

Tout cela me rappelle douloureusement quelque chose. En 2007 déjà, Dan Cederholm nous présentait do­WebSites­Need­To­Look­Exactly­The­Same­In­Every­Browser.com (je vous épargne le click : la réponse est non). Il y a près de 20 ans, la discussion portait sur des aspects visuels beaucoup plus triviaux, tels que les coins arrondis et les ombres portées, mais le sentiment reste vrai aujourd’hui : il est totalement absurde d’envoyer des centaines de kilo-octets de JavaScript pour donner à un site par ailleurs statique une navigation souple et douce. De nos jours, il suffit d’une ligne de CSS¹ et, dans le pire des cas, les navigateurs qui ne le prennent pas en charge parcourent votre site comme ils ont toujours été conçus pour le faire. Votre escalator est devenu un escalier.

La plateforme Web évolue lentement, et je comprends que cela puisse être frustrant pour les développeurs qui veulent innover, mais plus d’une décennie d’expérience en matière de conseil m’a appris à maintes reprises que l’alternative est beaucoup plus restrictive à long terme. Ce qui est tout nouveau aujourd’hui commence à montrer des signes de vieillissement beaucoup plus rapidement que quelque chose qui a déjà résisté à l’épreuve du temps.

Chaque couche d’abstraction réalisée dans le navigateur vous éloigne de la plateforme, vous enferme davantage dans un cadre et vous éloigne de la performance.

Je reste convaincu que le développeur moyen n’en sait pas assez sur l’analyse commerciale et que l’analyste commercial type n’en sait pas assez sur le développement pour réconcilier pleinement les deux côtés de la médaille. Des discussions plus approfondies et plus équilibrées, à long terme, doivent être menées par les deux parties, car le verrouillage (et son coût permanent) est bel et bien réel, et les paillettes d’aujourd’hui seront rapidement le boulet de demain.

Je ne suis pas contre les frameworks front et, croyez-moi, je ne suis pas assez naïf pour croire que la seule chose qu’un frameworks front apporte, ce sont des transitions entre pages agréables, mais si vous vous apprêtez à en utiliser un, il faudrait que je ne sois pas en mesure de pouvoir le détecter.

Si vous optez pour un frameworks ou, à défaut, pour une Single Page Application, pensez sérieusement au long terme et assurez-vous de faire du très bon travail.

C’est Nolan Lawson qui a le mieux résumé la situation lorsqu’il a déclaré que « la meilleure Single Page Application est meilleure que la meilleur site Web multi-page ; la Single Page Application moyenne est pire que le site Web multi-page moyen ».