Rester à jour : lire les spécifications et propositions

Le développement d’interfaces évolue rapidement. De nouveaux CSS, JS et API de navigateur sont publiés chaque trimestre. Les ingénieurs confirmés n’attendent pas les articles de blogue : ils lisent les sources originales, notamment les projets du W3C, les propositions de TC39, les spécifications du CSS WG et les pages d’état de l’implémentation des navigateurs.

TC39 est le comité qui fait évoluer JavaScript. Les propositions passent par 5 étapes : 0 (ébauche initiale), 1 (proposition), 2 (brouillon), 3 (candidate), 4 (finalisée et intégrée à ECMAScript). L’étape 3 est celle à partir de laquelle il est généralement raisonnable de miser dessus (les navigateurs l’implémentent et sa syntaxe est figée).

Chaque proposition se trouve sur github.com/tc39/proposal-NAME. Le README explique la motivation, la syntaxe et fournit des exemples. La branche « texte de spécification » contient la grammaire formelle. Fonctionnalités récemment intégrées : enregistrements et tuples, opérateur de pipeline, décorateurs v3 et assistants d’itérateur.

github.com/tc39/proposals : liste de toutes les propositions avec leur étape. 2ality.com : le blogue d’Axel Rauschmayer résume chaque réunion. v8.dev : le moteur V8 de Google intègre les propositions le plus rapidement ; ses articles les expliquent.

W3C standardise CSS, ARIA et les API web. WHATWG maintient HTML, DOM, Fetch et URL, qui constituent les « standards évolutifs ». Les deux organismes travaillent publiquement sur GitHub. Tout le monde peut signaler des problèmes dans le dépôt html de WHATWG.

Le CSS WG publie continuellement des spécifications : requêtes de conteneur, :has(), imbrication CSS, transitions de vue, positionnement d’ancres et animations pilotées par le défilement. Suivez son activité sur github.com/w3c/csswg-drafts et sur le blogue du CSS WG.

Même une proposition à l’étape 4 n’est pas utilisable tant que les navigateurs ne l’ont pas publiée. Consultez : caniuse.com (vue générale), chromestatus.com (Chrome), webkit.org/status (Safari), platform-status.mozilla.org (Firefox).

web.dev/baseline indique quelles fonctionnalités sont « disponibles depuis peu » (dans la dernière version de tous les navigateurs majeurs) et « largement disponibles » (depuis environ 30 mois). C’est une excellente ressource pour déterminer ce qu’il est possible de publier sans risque.

1) web.dev/blog — l’équipe Google chargée des relations avec les développeurs web. 2) WebKit blog — les annonces de Safari. 3) v8.dev/blog — JavaScript dans V8 et Chrome. 4) CSS-Tricks newsletter. 5) JavaScript Weekly / Frontend Focus. 6) This Week in WebKit.

Lisez le code source des bibliothèques que vous utilisez. React, Vue et Vite sont tous disponibles sur GitHub. Comprendre comment leurs mainteneurs ont résolu des problèmes complexes est l’un des meilleurs moyens de progresser.

Ne vous contentez pas de lire des informations sur les nouvelles fonctionnalités : essayez-les. Créez une petite démonstration avec l’API View Transitions, avec le sélecteur :has() ou avec les nouvelles méthodes Set d’ECMAScript. On n’apprend vraiment qu’en pratiquant.

Chaque nouveauté séduisante n’a pas sa place en production. Demandez-vous : est-elle disponible dans Baseline ? Fonctionne-t-elle dans nos navigateurs cibles ? Quel est le coût de la compatibilité rétroactive ? Quel problème résout-elle que l’approche actuelle ne résout pas ? Mon équipe la maîtrise-t-elle ? Adoptez les nouveautés délibérément, et non par réflexe.

Signalez des problèmes dans les propositions de TC39 et de WHATWG en fournissant des cas d’utilisation et des contre-exemples : les comités écoutent réellement les développeurs. Publiez vos démonstrations en logiciel libre. Commentez les propositions qui vous intéressent. C’est ainsi que la plateforme progresse.

Les ingénieurs confirmés pensent en années, et non en sprints. Lire les spécifications fait de vous la personne qui connaissait :has() six mois avant tout le monde, qui a choisi la bonne bibliothèque de récupération des données avant que l’équipe ne rencontre des problèmes et qui comprenait les composants serveur avant la migration. Cette capacité d’anticipation produit des effets cumulatifs.

À partir de quelle étape de TC39 une proposition JavaScript est-elle généralement considérée comme suffisamment sûre pour commencer à être utilisée en production avec un transpileur ?

Lisez les sources originales : propositions de TC39, spécifications du W3C et de WHATWG, projets du CSS WG. L’étape 3 ou une étape ultérieure est considérée comme sûre pour la production avec un transpileur. Suivez l’évolution grâce à caniuse, chromestatus, webkit.org/status et Baseline (web.dev/baseline). Abonnez-vous à web.dev, au blogue WebKit, à v8.dev, à CSS-Tricks et à JS Weekly. Créez des démonstrations pour assimiler les concepts. Évaluez avec esprit critique. Contribuez en retour. La réflexion à long terme produit des effets cumulatifs : l’ingénieur qui lit les spécifications prend les devants.