J'ai écrit la majeure partie de ce billet en 2022, mais je pense qu'il tient la route en 2024 et j'ai donc décidé de le publier pour la postérité. Je n'aime pas vraiment faire des billets comme celui-ci - je préférerais partager des apprentissages ou des conseils inoffensifs, mais il s'avère que j'ai aussi des opinions 😓 Désolé !2024-02-21 : J'ai ajouté quelques réflexions à la fin du billet.
Depuis que j'ai quitté Mozilla et que je suis retourné au développement Web à plein temps, j'ai découvert quelques surprises. Il s'avère que le développement Web est en fait assez difficile, que les développeurs Web sont en fait très intelligents, et que certains de ces frameworks et techniques dont nous nous moquions en tant qu'ingénieurs navigateurs ne sont pas si mauvais. Oups.
En même temps, il s'avère que certains développeurs Web ont des idées sur les navigateurs et le Web qui, en tant qu'ancien ingénieur navigateur et éditeur de normes, me laissent un peu dubitatif.
Voici quelques-unes des choses qui m'ont surpris.
- "Les ingénieurs spécialisés dans les navigateurs connaissent très bien le développement Web."
- "Les personnes qui élaborent les spécifications du Web connaissent très bien le développement du Web."
- "Les développeurs Web connaissent très bien le développement Web"
- "Les navigateurs ne sont pas conçus pour faire fonctionner les SPA."
- "Les MPA remplaceront les SPA"
- "Tous les sites devraient fonctionner sans JavaScript"
- "Le développement web ne devrait pas avoir besoin d'une étape de construction."
- "Mon blog est représentatif du développement web en général"
"Les ingénieurs spécialisés dans les navigateurs Web connaissent très bien le développement Web."
Il est facile d'imaginer que les ingénieurs des navigateurs Web, qui écrivent le code qui constitue la plate-forme Web, doivent connaître le Web de l'intérieur comme personne d'autre.
Le problème, c'est qu'il est difficile d'écrire des navigateurs Web.
La plupart des ingénieurs spécialisés dans les navigateurs se concentrent sur un domaine particulier qu'ils connaissent très bien et dont ils n'ont qu'une compréhension superficielle des autres domaines. En outre, les ingénieurs spécialisés dans les plates-formes de navigateur écrivent du code C++ et Rust à longueur de journée, avec quelques cas de test JavaScript très simples. En outre, ils contribuent à un référentiel massif où quelqu'un d'autre s'occupe de tout l'outillage.
Par conséquent, dans leur travail quotidien, les ingénieurs navigateurs ne se battent pas contre webpack, n'essaient pas de comprendre les erreurs TypeScript pleine page (ils ont les erreurs de template C++ pour combler ce vide dans leur vie), n'essaient pas de faire en sorte que Safari sur iOS se comporte comme les autres navigateurs, ne se battent pas avec CSS à l'échelle, n'essaient pas d'évaluer si le dernier SSR/SSG/island framework vaut la peine d'être investi, ils ne refactorisent pas d'énormes bases de code JS pour un découpage plus optimal, ils ne déposent pas de problèmes exaspérés sur GitHub parce que la dernière version d'une de leurs dépendances a cassé leur application, ils n'essaient pas de mettre tous leurs outils d'accord sur ESM vs CJS, et ils ne perdent pas le sommeil à se demander s'ils ont choisi la bonne approche de gestion des états ou s'ils devraient réécrire l'ensemble pour la dixième fois.
En bref, ils ne font pas du développement Web tous les jours et en savent donc beaucoup moins sur le développement Web réel que les développeurs Web ne l'espèrent probablement.
Les ingénieurs qui travaillent sur les outils de développement des navigateurs et sur le front-end des navigateurs utilisent souvent le langage JS au quotidien et sont certainement plus conscients des problèmes, mais ils sont encore à quelques degrés de distance du développement Web normal. Par exemple, ils ne doivent cibler que les fonctionnalités de la plate-forme d'un seul moteur de navigateur, et souvent qu'une seule version de navigateur (pouvoir utiliser les nouvelles fonctionnalités sans se soucier de la compatibilité est extraordinaire), ils n'ont pas à se soucier de la taille des paquets, ni des serveurs, ni de la mise hors ligne, ni de tant d'autres problèmes qui rendent le développement Web difficile.
Il est évident que certains ingénieurs navigateurs ont des projets de loisir, mais les contraintes d'un projet de loisir sont très différentes de celles d'une startup où l'on vit ou meurt du succès de son application Web.
J'ai commencé ma carrière dans le graphisme et le développement Web et même après avoir commencé à contribuer à Firefox, j'ai travaillé dans une société de développement Web à Osaka pendant un certain temps et j'ai également produit quelques applications Web chez Mozilla Japon. Cependant, lorsque j'ai quitté Mozilla et que je me suis remis à plein temps au développement Web, j'ai été choqué de voir à quel point les choses avaient changé et à quel point j'en savais peu sur le sujet.
Mon expérience en tant qu'ingénieur navigateur a été incroyablement utile dans le développement Web, notamment parce que je sais où chercher, à qui demander et où déposer les bogues, mais je me tromperais si je disais que le fait d'être ingénieur navigateur me qualifie automatiquement en tant que développeur Web.
Lors de mon passage chez Mozilla, l'époque de Firefox OS a été de loin la plus agréable. Nous avions des équipes internes qui construisaient des applications Web mobiles réelles que nous, en tant qu'équipe chargée de la plateforme, devions déboguer et faire réussir, ce qui était notre plus grande priorité. J'ai vu comment les événements transitionend pouvaient être peu fiables et rendre les applications Web boguées et trop compliquées, et j'ai donc proposé et mis en œuvre l'événement transitioncancel et la promesse Animation.finished de Web Animations.
Mais même en travaillant côte à côte avec des développeurs Web, je n'ai pas pu me préparer à redevenir un développeur Web à plein temps. La plupart du temps, les ingénieurs navigateurs travaillent dans un monde différent de celui des développeurs Web et ne sont pas forcément les super-héros du développement Web que nous imaginons.
"Les personnes qui élaborent les spécifications du Web connaissent très bien le développement Web"
D'accord, mais les personnes qui travaillent sur les normes et les spécifications du Web (qui, il s'avère, sont pour la plupart des ingénieurs de navigateurs) doivent bien connaître le développement Web, n'est-ce pas ?
En 2012, Brendan Eich a fait remarquer que "l'élaboration de normes, comme l'élaboration de lois, est sans aucun doute l'élaboration de saucisses", faisant référence à la citation suivante de John Godfrey Saxe :
Les lois, comme les saucisses, cessent d'inspirer le respect dans la mesure où nous savons comment elles sont fabriquées.
Cette illusion ne dure généralement pas le temps de la première réunion du groupe de travail. Malgré les meilleures intentions, il arrive que des décisions soient prises, au moins en partie, en fonction du charisme ou de la force de caractère d'une personne, des personnes présentes dans la pièce à ce moment-là, de l'état de fatigue de chacun ou, si j'ose dire, peut-être même du besoin de quelqu'un d'expédier une fonctionnalité afin de remplir son dossier de promotion.
Cela semble très cynique, alors permettez-moi d'apporter deux précisions.
Tout d'abord, les membres de ces groupes sont des personnes bien intentionnées et merveilleuses. En outre, ils sont souvent conscients de leurs limites et font de leur mieux pour susciter des réactions de la part des développeurs Web. Malheureusement, je n'ai encore jamais vu un groupe y parvenir avec succès. Il existe des sondages Twitter/X, par exemple, mais ils ont tendance à n'être remplis que par les développeurs Web à la pointe de la technologie et sont facilement faussés par la personne qui fait passer le mot du sondage.
Deuxièmement, je n'ai pas beaucoup d'expérience avec les spécifications du WHATWG comme HTML et DOM où les décisions semblent être prises de manière asynchrone ("toute décision prise pendant les réunions en personne doit être considérée comme non contraignante" - réunions du WHATWG), mais j'ai l'impression qu'ils semblent prendre de meilleures décisions. Des personnes comme Anne van Kesteren, Simon Pieters et Domenic Denicola connaissent probablement le Web mieux que quiconque sur la planète. Mais ce n'est pas la même chose que de connaître le développement Web.
"Les développeurs Web connaissent très bien le développement Web"
En tant qu'ingénieur spécialisé dans les navigateurs, il est très satisfaisant de livrer une nouvelle fonctionnalité de plate-forme. Il y a des articles à ce sujet dans Smashing Magazine, des astuces CSS et Twitter/X s'enflamme pour la nouvelle. Il est facile de penser que le monde entier est désormais au courant de cette nouvelle avancée dans les capacités du Web.
Il y a quelques années, certains membres de l'équipe japonaise de Mozilla ont décidé d'interroger des développeurs Web locaux à Tokyo pour savoir de quels outils de développement ils auraient besoin.
Les résultats ont été surprenants.
Beaucoup d'entre eux ne connaissaient pas les nouvelles fonctionnalités CSS qui avaient été livrées il y a 10 ans. Qui plus est, même lorsque nous leur en avons parlé, ils n'ont pas semblé très enthousiastes. Ils se débrouillaient très bien avec jQuery et WordPress, merci.
En revanche, ils rencontraient des difficultés du type : "Lorsque je montre à des clients un site en mode responsive design, si la fenêtre n'est pas entourée d'une maquette d'iPhone, les clients ne peuvent pas comprendre qu'ils regardent un aperçu de la façon dont le site sera affiché sur un smartphone. J'ai vraiment besoin de cette maquette d'iPhone".
En tant qu'ingénieur spécialisé dans les navigateurs et impliqué dans le développement de nouvelles normes Web, j'ai été un peu déçu, mais j'ai surtout eu l'impression que les contraintes imposées à ces personnes qui gagnent leur vie en livrant des sites et des applications Web étaient énormes.
Contrairement aux personnes qui travaillent sur des navigateurs ou des start-ups bien financées de la Silicon Valley, beaucoup d'entre elles travaillent dans de petites boutiques et sont soumises à une pression considérable pour livrer quelque chose rapidement et passer ensuite au projet suivant afin de payer les factures. Ils n'ont pas le luxe de passer une matinée à bricoler sur les nouvelles technologies et préfèrent se tourner vers des solutions éprouvées et fiables dont ils ont l'expérience.
"Les navigateurs ne sont pas faits pour faire tourner des SPA"
Une autre surprise que j'ai eue en revenant du développement de navigateurs au développement Web a été certaines affirmations sur le fonctionnement des navigateurs.
Lorsque je travaillais sur les animations, j'ai été surpris par le nombre de personnes qui croyaient que certaines animations "tournaient sur le GPU" (le navigateur peut décharger certaines animations sur un processus ou un thread séparé qui met à jour les animations en utilisant le GPU pour composer ou même peindre chaque image, mais il ne les décharge pas complètement sur le GPU), mais c'était un malentendu assez mineur comparé à d'autres qui sont lancés comme "les navigateurs ne sont pas faits pour faire tourner des SPA (applications à page unique)".
Je crois que l'argument est qu'à l'origine, les navigateurs chargeaient le contenu à partir du réseau, en l'étalant progressivement et en le rendant, et qu'ils ont été fortement optimisés pour cela. Le contenu dynamique est apparu plus tard et a donc été moins fortement optimisé.
Ayant travaillé sur un navigateur par intermittence pendant près de vingt ans, je ne suis pas convaincu que ce soit le cas, ou du moins plus maintenant.
Après tout, les outils front-end et de développement de Firefox sont, en fait, des SPA. Les outils de développement en particulier sont écrits en utilisant React et Redux et sont dans tous les sens une SPA.
L'argument selon lequel les navigateurs sont incapables de gérer des arborescences DOM complexes et de longue durée avec des modifications dynamiques apportées par JavaScript est contredit par le navigateur lui-même.
On pourrait avancer l'argument selon lequel, sur mobile, les navigateurs ne sont pas optimisés pour faire fonctionner les SPA. Après tout, sur Android, Firefox est passé d'un navigateur chrome rendu HTML à un navigateur chrome natif afin d'améliorer les performances. Je ne suis pas en mesure de commenter les contraintes de performance particulières qui ont conduit à ce changement, mais un blog de l'époque suggère qu'il était lié à l'amélioration du temps de démarrage de l'application et des performances de panoramique et de défilement, ce qui n'indique pas que les navigateurs sont déficients pour gérer les SPA par rapport à d'autres architectures.
"Ok, peut-être que les navigateurs peuvent gérer des arbres DOM complexes à longue durée de vie avec des changements dynamiques fréquents, mais les SPA ont tendance à avoir de gros paquets JS qui sont lents à télécharger et à analyser, ce qui bloque le rendu initial". C'est un argument juste, mais c'est un argument pour des bundles initiaux bloquant le rendu plus petits, qui s'applique également à votre site WordPress moyen, et non un argument selon lequel les navigateurs sont en quelque sorte inadaptés à l'exécution des SPA.
"Les MPA vont remplacer les SPA"
Puisque nous parlons des SPA et de "la seule vraie façon d'écrire des applications Web", une variante plus récente de l'argument "les navigateurs ne peuvent pas gérer les SPA" est "les MPA (applications multi-pages) vont remplacer les SPA".
Je suis assez enthousiaste à propos des MPA. Plus précisément, en tant que personne impliquée dans de nombreuses spécifications d'animation, je suis enthousiasmé par la spécification des transitions de vue. C'est quelque chose que nous voulions faire chez Mozilla depuis un certain temps, en particulier à l'époque de Firefox OS, et nous avons fait une proposition dans ce sens. Bravo à Jake et à d'autres pour l'avoir enfin réalisé.
Les transitions d'affichage ont été mises en œuvre à l'origine pour les SPA, mais elles ont été adaptées pour fonctionner avec les MPA et, dans la mesure où elles rendent les sites multipages plus agréables, elles constituent un ajout très apprécié.
Cependant, en s'appuyant sur le raisonnement selon lequel les SPA sont mauvaises, il semble y avoir une tendance à supposer que les MPA sont l'avenir et que les SPA sont en voie de disparition.
Contrairement aux points précédents de ce billet, ma surprise face à ce point de vue n'est pas basée sur mon expérience de travail sur les navigateurs, mais sur mon expérience plus récente de travail sur les applications Web.
Tout d'abord, qu'entendons-nous par MPA ?
D'après ce que j'ai compris, alors que les SPA se caractérisent par un ou deux arbres DOM de longue durée qui sont fréquemment mis à jour par des scripts, les MPA mettent principalement à jour le contenu en naviguant vers différentes ressources HTML servies par le réseau. Il n'est pas nécessaire qu'il s'agisse des navigations les plus importantes - il peut s'agir d'une navigation dans une <iframe>, par exemple. De même, les SPA peuvent utiliser les <iframe> comme moyen de découpage, mais il y a une différence dans la manière dont le contenu est généralement mis à jour.
Selon cette définition, Google Docs est une SPA car, bien que chaque document soit servi comme une ressource distincte, la plupart du temps, vous interagissez avec un seul document qui est continuellement mis à jour par JavaScript. YouTube serait probablement considéré comme une MPA, mais il pourrait en fait être mis en œuvre comme une SPA afin d'atténuer les changements de contenu, en interceptant les navigations et en remplaçant le contenu par un script - c'est-à-dire jusqu'à ce que les transitions d'affichage puissent aider à cela.
Dans un cas comme dans l'autre, ma surprise face à l'idée que les MPA remplaceront toutes les SPA est simple : Comment Figma ou Photoshop pour le web fonctionneraient-ils en tant que MPA ? Ou Slack, ou Discord, ou Google Maps ?
Je travaille actuellement sur une application Web mobile offline-first qui stocke les données localement et les synchronise avec le serveur. Désireux d'être à la pointe de la technologie Web, j'ai cherché à savoir comment nous pourrions adopter les MPA.
Pour faire court, si nous voulons conserver l'interface utilisateur souhaitée, qui comporte des panneaux à navigation indépendante, ainsi que notre exigence de mise en ligne, nous pourrions introduire des <iframe> pour diviser certaines fonctionnalités en requêtes HTML distinctes (par opposition à des requêtes de scripts distinctes) et nous pourrions probablement même effectuer un pré-rendu de certains morceaux parfois. Le problème est que cela décuplerait la complexité (la synchronisation bidirectionnelle deviendrait une synchronisation tridirectionnelle pour commencer) tout en n'apportant aucun avantage aux clients - au lieu de cela, cela conduirait presque certainement à plus de bogues, plus de latence, et à une livraison plus lente des fonctionnalités.
Étant donné que notre application n'est pas encore commercialisée, je me rends compte que c'est un argument assez faible puisque personne ne peut examiner l'application et suggérer une meilleure approche, alors je vous demande simplement de me faire confiance sur ce point. J'ai essayé. J'ai vraiment essayé. Ce n'est tout simplement pas la bonne architecture pour cette application particulière et je suis surpris par la suggestion que tout devrait être une MPA.
"Tous les sites devraient fonctionner sans JavaScript"
Pour poursuivre sur le thème des meilleures pratiques en matière de développement web, construire un site qui fonctionne sans JavaScript est un objectif admirable. Cela signifie probablement qu'il se dégrade gracieusement, qu'il n'y a pas de JS qui bloque le rendu initial et qu'il fonctionne sur un large éventail de navigateurs. Mais j'ai été surpris de voir à quel point cet objectif devient souvent dogmatique : "tous les sites devraient fonctionner sans JavaScript".
Je suppose qu'il est facile d'arriver à cette conclusion si votre site est capable de fonctionner sans JavaScript (voir "Mon blog est représentatif du développement Web en général"
, mais cela me semble un peu myope.J'ai déjà mentionné Figma et Photoshop pour le web ; il est difficile d'imaginer comment ils pourraient fonctionner sans JavaScript. Il en va de même pour les outils de développement d'un navigateur. Ou même Parapara Animation !
En outre, bien que de nombreux défenseurs de JS soient également préoccupés par l'accessibilité, JavaScript est souvent nécessaire pour rendre une application accessible.
Les responsables de l'accessibilité chez Mozilla m'ont appris une chose sur la navigation au clavier : la navigation par tabulation doit être assez grossière. En d'autres termes, vous utilisez la touche Tab pour accéder au groupe de contrôle (par exemple, la barre d'outils), puis vous utilisez les touches fléchées pour vous déplacer à l'intérieur de ce groupe. Cela vous permet de vous déplacer plus rapidement dans une application sans avoir à utiliser la touche Tab pour chaque contrôle. Le WAI appelle cela un "tabindex itinérant".
Cependant, pour mettre en œuvre ce type de navigation au clavier à gros grain, vous aurez besoin de JavaScript. Si vous voulez rendre la navigation basée sur les touches fléchées bidimensionnelle, vous aurez besoin d'encore plus de JavaScript. Peut-être qu'un jour nous comblerons cette lacune dans la plateforme (je vous regarde, focusgroup), mais pour l'instant vous ne devriez pas avoir honte d'utiliser JavaScript côté client pour rendre votre application accessible.
Honnêtement, je pense que certains sites devraient utiliser davantage de JavaScript.
Par exemple, la documentation d'Eleventy semble éviter d'utiliser le JavaScript côté client pour la plupart. Comme Eleventy prend en charge plusieurs langages de modélisation, il fournit des exemples de code dans chacun de ces langages. Malheureusement, il n'enregistre pas la langue que vous avez sélectionnée, de sorte que si la langue choisie n'est pas celle par défaut, vous êtes obligé de changer d'onglet pour chaque exemple de code. Un peu de JavaScript côté client rendrait l'expérience beaucoup plus agréable pour les utilisateurs.
Mise à jour (2024-01-11) : Il semble qu'Eleventy ait pris en compte ces commentaires et corrigé ce problème. Nous vous remercions ! 🙏
"Le développement web ne devrait pas avoir besoin d'une étape de construction"
Bien qu'à peu près tout ce qui figure dans ce billet date de 2022, je n'ai pas pu résister à l'envie d'y ajouter une idée récente qui m'a surpris.
Notre dernier arrêt sur le train du dogme du développement Web est un point de vue qui a été évoqué à plusieurs reprises mais qui me surprend toujours. L'interprétation la plus récente que j'ai vue était quelque chose comme "nous sommes tellement aveugles et têtus que nous avons fini avec une chaîne d'outils extrêmement complexe, mais nous devrions vraiment être en mesure de livrer des applications Web sans aucune étape de construction".
Pour quelqu'un qui a passé la majeure partie de sa carrière à travailler avec des langages compilés, le désir de se passer d'une étape de compilation est surprenant. Les choses que font les ingénieurs compilateurs me surprennent. Ce sont des génies qui superposent une optimisation intelligente à une autre optimisation intelligente, transformant mon code très moyen en quelque chose de méconnaissable et d'incroyablement rapide. J'aimerais que la magie des compilateurs s'applique davantage à mon développement Web.
Il est évident que JavaScript présente ses propres défis puisqu'il peut être très difficile de déterminer statiquement les effets secondaires d'une certaine opération, mais je suis sûr qu'il y a encore de la place pour explorer l'optimisation de JavaScript au moment de la compilation.
Les développeurs Web semblent s'accorder sur l'optimisation des images et la pré-génération de pages HTML statiques lorsque cela s'avère judicieux, pourquoi y a-t-il une résistance à l'optimisation des codes également ? Pourquoi reporter à l'exécution des calculs et des E/S qui peuvent être effectués une seule fois au moment de la construction ? Au moins, je n'ai aucune envie d'envoyer mes commentaires d'un mégaoctet de long maudissant iOS Safari à chaque utilisateur et à chaque demande.
Peut-être que 2024 sera l'année où les frameworks front-end Rust/WASM côté client commenceront à s'imposer et si c'est le cas, nous ferions mieux de nous habituer à avoir une étape de compilation !
"Mon blog est représentatif du développement Web dans son ensemble".
Un certain nombre des points évoqués ci-dessus pourraient être résumés par la formule "Mon blog est représentatif du développement Web dans son ensemble". En effet, en passant d'ingénieur navigateur à développeur Web, la plupart des notions sur le développement Web qui m'ont surpris sont le résultat d'une extrapolation de leur expérience du Web d'une manière qui ne correspond pas à la mienne.
Depuis que j'ai quitté Mozilla il y a plus de quatre ans, j'ai passé la plupart de mon temps à travailler sur une application Web. J'ai également passé beaucoup trop de temps à créer ce blog. Étonnamment, en ce qui concerne l'outillage, l'architecture ou les fonctionnalités de la plate-forme Web utilisées, je n'ai trouvé pratiquement aucun chevauchement entre les deux. C'est un peu comme si les blogs et les applications existaient dans des coins complètement disparates du paysage du développement Web.
Mon application est une masse de code TypeScript, mon blog n'utilise pratiquement pas de JavaScript côté client. Mon application est extrêmement compliquée par la synchronisation bidirectionnelle des données, mon blog est en lecture seule. Mon application utilise webpack, des tests E2E Playwright, un framework de composants et une bibliothèque de gestion d'état, mon blog n'utilise rien de tout cela.
Si vous êtes principalement engagé dans l'un ou l'autre, il est facile de penser que c'est à cela que ressemble le développement Web. En réalité, le développement Web est probablement plus diversifié qu'aucun d'entre nous ne l'imagine.
Conclusion
Il y a d'autres notions que j'ai trouvées surprenantes, mais le thème commun dans ce qui précède est qu'il est facile de supposer que notre expérience du Web est représentative du développement Web en général.
Passer du développement de navigateurs au développement Web a été une leçon d'humilité, car c'est tellement plus large et plus profond que ce que je connaissais. J'ai beaucoup plus de respect pour les développeurs Web, en particulier ceux des petites boutiques Web et des startups qui vivent ou meurent du succès de leurs applications Web.
Si c'est votre cas, j'espère que la lecture de ce billet vous confortera dans l'idée que, même si les ingénieurs navigateurs, les éditeurs de normes et les autres développeurs Web insistent sur une façon particulière de faire les choses, vous connaissez vos contraintes mieux que quiconque et vous faites probablement les choses très bien.
Réflexions quelques mois plus tard
Depuis la publication de cet article, j'ai reçu des commentaires très utiles que je résume ci-dessous :
- Certaines personnes ont fait remarquer que le fond de beaucoup de sentiments anti-JavaScript et anti-SPA est une réaction au fait de voir des sites statiques rendus comme des SPA React, ce qui est une très mauvaise chose. C'est un contexte utile que je n'avais pas apprécié.
- D'autres ont précisé que l'argument "pas d'étape de construction" concerne davantage le développement local que les actifs de production. Cela a beaucoup de sens et c'est quelque chose que je peux comprendre.
- Mon propos n'était pas de dire que vous devriez avoir une étape de compilation, mais simplement de dire que, venant du développement de navigateurs, j'ai été surpris par le sentiment antiétape de compilation parce que je suis habitué aux compilateurs et je serais intéressé de voir ce qu'ils peuvent faire de plus pour nous.
- Certaines personnes ont contesté certains des derniers points parce que je n'ai pas réussi à résumer clairement mon principal argument. La voici :
J'ai travaillé sur des navigateurs pendant plus de dix ans et je suis toujours impliqué dans les normes Web et le développement de navigateurs. J'aime la plateforme et j'encourage les autres à l'utiliser pleinement.
Ce que je conteste, ce sont les termes absolus avec lesquels les meilleures pratiques de développement Web sont parfois affirmées. Les médias sociaux consacrés au développement du web peuvent être féroces, ce dont j'ai été protégé lorsque je travaillais sur des navigateurs.
Je n'essaie certainement pas d'établir un nouveau dogme, mais simplement de repousser les limites et de dire que l'utilisation de JavaScript, l'écriture d'une SPA et la mise en place d'une étape de construction sont parfois le bon choix et qu'il ne faut pas se sentir mal à l'aise à ce sujet.
Source : Brian Birtles
Et vous ?
Quel est votre avis sur le sujet ?Voir aussi :
Trois recommandations pour sécuriser les sites web côté navigateur, par Hervé Hulin Les microservices ne sont pas le problème. Ce sont les personnes incompétentes qui le sont, par Dmitry Non