Quatre époques de frameworks JavaScript

En 2012, j'ai commencé à coder principalement en JavaScript. Une fois, j'ai créé une application PHP, un CMS de base et un site Web du début à la fin pour une entreprise locale, et l'entreprise a décidé de la réécrire et d'ajouter quelques fonctionnalités.

Le chef de projet voulait que j'utilise .NET, en partie parce que c'est ce qu'il savait, mais aussi parce qu'il voulait que l'application ressemble à une application native - pas d'actualisation de page ni de longues attentes pour les actions. Après quelques recherches et prototypage, j'ai convaincu mon manager que je pouvais faire ces choses en utilisant un nouveau framework JS qui commençait tout juste à émerger à l'époque.

Le premier framework que j'ai choisi était en fait Angular 1. Ayant construit une application assez volumineuse et utilisant le backend de FuelPHP avant de rencontrer des problèmes avec le routeur - elle scintillait à chaque fois qu'une route/prise enfant était restituée et j'avais vraiment l'impression qu'elle était en cours de conception. Ce scénario n'a pas été envisagé à l'époque. .

​Plus tard, quelqu'un m'a recommandé Ruby on Rails + Ember Après l'avoir essayé, j'ai pensé que cela fonctionnait très bien. J'aime aussi l'idée des deux cadres, j'aime ces écologies communautaires, et dans l'ensemble, cela a été très productif par rapport aux alternatives de l'époque.

Beaucoup de choses ont changé depuis – des frameworks ont émergé et beaucoup évolué. L’idée selon laquelle vous pouviez créer des applications avec JavaScript dans le navigateur est passée d’une pratique marginale à une pratique standard. L'infrastructure que nous avons construite a complètement changé, ouvrant la voie à un nouvel ensemble de possibilités.

Pendant cette période, il y avait aussi pas mal de compétition et de conflits entre diverses idées. Quel framework JavaScript utiliser, comment écrire du CSS, programmation fonctionnelle ou orientée objet, comment gérer au mieux l'état, quel système ou outil de construction est le plus flexible et le plus rapide, etc. Avec le recul, il est drôle de constater à quel point nous discutons souvent de mauvaises choses et ignorons certaines considérations prospectives. Bien sûr, c’est aussi du recul.

J'avais donc envie de faire une rétrospective, de revenir sur les dernières décennies de développement JavaScript et de voir jusqu'où nous en sommes. On peut grossièrement le diviser en quatre époques principales. :

• Ère originale
• Le premier framework
• Couche de vue centrée sur les composants
• Cadre full-stack

Chaque époque a ses propres thèmes et contradictions fondamentales, et en même temps, elle veut aussi tirer des leçons clés , Et avancez régulièrement.

Aujourd'hui, le débat continue. Le Web devient-il trop volumineux ? Le site Web moyen doit-il vraiment être écrit en React ? Devons-nous même utiliser JavaScript ? Bien entendu, le présent ne peut pas représenter l’avenir, et le cadre existant sera très probablement remplacé à l’avenir. Cependant, il s’appuie également sur certaines perspectives existantes pour nous aider à avancer.

Années originales

JavaScript a été publié pour la première fois en 1995. Comme je l'ai mentionné ci-dessus, j'ai commencé à écrire du JS en 2012, près de 20 ans plus tard, près du début de ce que j'appelle la première ère du framework. Vous pouvez supposer que je passe sous silence une grande partie de l'histoire ici et que cette époque pourrait être divisée en de nombreuses sous-ères, chacune avec ses propres modèles, bibliothèques, outils de construction, etc.

C’est-à-dire que je ne peux pas écrire sur des choses que je n’ai pas vécues. Lorsque j’ai commencé à écrire des applications front-end, la nouvelle génération de frameworks commençait tout juste à mûrir. Angular.js, Ember.js, Backbone et plus encore.

Avant cela, la technologie la plus avancée était celle des bibliothèques telles que jQuery et MooTools. Ces bibliothèques étaient importantes à leur époque - elles aidaient à atténuer les différences importantes dans la manière dont les navigateurs implémentaient JavaScript.

Par exemple, la façon dont IE implémente les événements est complètement différente de celle de Netscape : faire bouillonner les événements et capturer les événements. C'est pourquoi nos standards actuels implémentent enfin les deux, mais d'ici là, nous devons utiliser des bibliothèques pour écrire du code qui fonctionne sur les deux navigateurs.

Ces bibliothèques sont principalement utilisées pour créer de petits composants d'interface utilisateur indépendants. La majeure partie de la logique métier de l'application s'effectue toujours via des formulaires et des requêtes HTTP standard : le HTML est rendu sur le serveur et servi au client.

Il n’existe aucun outil de construction à proprement parler de nos jours, du moins à ma connaissance. À l'époque, JavaScript n'avait pas de modules (du moins pas de modules standard), il n'y avait donc aucun moyen d'importer du code. Tout est mondial et c'est très difficile à organiser.

Dans cet environnement, il est compréhensible que JS soit souvent considéré comme un langage jouet plutôt que comme quelque chose que vous utilisez pour écrire une application complète. La chose la plus courante que nous faisions à l'époque était d'utiliser jQuery, d'écrire des scripts pour certains widgets d'interface utilisateur, et c'était tout.

Au fur et à mesure que le temps passait et que XHR était introduit et popularisé, les gens ont commencé à regrouper des parties de leurs processus d'interface utilisateur dans une page, en particulier pour les processus complexes qui nécessitaient de multiples interactions aller-retour entre le client et le serveur, mais l'application La plupart du programme reste sur le serveur.

Cela contraste fortement avec l’époque où les applications mobiles ont commencé à émerger. Depuis le début, les applications mobiles sur iOS et Android ont été des applications complètes écrites dans des langages pratiques™ comme Objective C et Java. De plus, ils sont entièrement pilotés par API : toute la logique de l'interface utilisateur se trouve sur l'appareil et la communication avec le serveur se fait uniquement au format de données. Cela a conduit à une meilleure expérience utilisateur et à une explosion des applications mobiles, menant directement au débat que nous avons aujourd'hui sur la question de savoir si le mobile ou le Web est meilleur.

Faire tout cela en JavaScript était initialement considéré comme ridicule. Mais au fil du temps, les candidatures ont commencé à devenir plus ambitieuses. Les réseaux sociaux ont ajouté le chat, les DM et d'autres fonctionnalités en temps réel, Gmail et Google Docs ont montré que des applications de bureau équivalentes pouvaient être écrites dans le navigateur, et de plus en plus d'entreprises se sont tournées vers l'écriture d'applications Web parce que le Web fonctionnait partout et était plus facile. -entretien à terme. Cela a fait avancer l’ensemble du secteur : il était désormais clair que JS pouvait être utilisé pour écrire des applications non triviales.

À l'époque, JavaScript n'avait pas toutes les fonctionnalités dont il dispose aujourd'hui, tout était global et nécessitait généralement de télécharger manuellement et d'ajouter chaque bibliothèque externe à un dossier statique. NPM n'existait pas encore, les modules n'existaient pas et JS n'avait pas la moitié des fonctionnalités dont il dispose aujourd'hui.

Dans la plupart des cas, chaque application est personnalisée, chaque page a des paramètres de plugin différents et chaque plugin dispose d'un système différent pour gérer l'état et le rendu des mises à jour. Afin de résoudre ces problèmes, le premier framework JavaScript a commencé à apparaître.

Les premiers frameworks

Vers la fin des années 2000 et le début des années 2010, les premiers frameworks JS ont commencé à apparaître spécifiquement pour l'écriture d'applications complètes côté client. Plusieurs frameworks célèbres de cette époque :

1. Backbone.js
2. Angular 1
3. Knockout.js
4. SproutCore
5. Ember.js
6. Meteor.js

Bien sûr, il y en a beaucoup d'autres, probablement plus. certains qui sont plus grands dans certains cercles. Ce sont ceux dont je me souviens, principalement parce que Xiao Ming les utilisait pour coder et qu'ils sont relativement populaires.

Il s'agit d'un cadre de génération qui entre en territoire inconnu. D’une part, ce qu’ils essayaient de faire était très ambitieux et beaucoup pensaient que cela ne réussirait jamais vraiment.

De nombreux opposants affirment que les applications JS à page unique (SPA) sont fondamentalement pires, et à bien des égards, ils ont raison : le rendu côté client signifie que les robots ne peuvent pas facilement explorer ces pages et que les utilisateurs doivent même attendre. prend quelques secondes pour commencer à dessiner l’application. Beaucoup de ces applications sont des cauchemars en matière d'accessibilité et ne fonctionnent pas du tout si JavaScript est désactivé.

D'un autre côté, nous n'avons aucune expérience dans la création d'applications complètes en JS, il existe donc des tonnes d'idées concurrentes sur la meilleure approche. La plupart des frameworks tentent d'imiter ce qui est populaire sur d'autres plates-formes, donc presque tous finissent par être une itération de Model-View-*. Model-View-Controller, Model-View-Producer, Model-View-ViewModel et ainsi de suite. Mais à la longue, ceux-ci ne sont pas vraiment efficaces : ils ne sont pas particulièrement intuitifs, et deviennent très vite très compliqués.

C'était aussi une époque où nous avons vraiment commencé à expérimenter la façon de compiler des applications JavaScript. Node.js a été publié en 2009, et NPM a suivi en 2010, introduisant des packages pour JavaScript (côté serveur).

CommonJS et AMD se battent pour savoir comment définir au mieux les modules JS, tandis que des outils de création comme Grunt, Gulp et Broccoli se disputent pour savoir comment combiner ces modules dans un produit final livrable.

Pour la plupart, il s'agit d'outils de type exécuteur de tâches très généraux qui peuvent vraiment créer tout ce qui se trouve être de la création de JavaScript - mais aussi HTML, CSS/SASS/LESS et bien d'autres qui entrent dans les applications Web.

Cependant, nous avons beaucoup appris de cette époque :

• Le routage basé sur les URL est la base. Les applications sans ce routage endommagent le Web, ce qui doit donc être pris en compte dès le départ dans le cadre.
• L'extension du HTML via un langage basé sur des modèles est une puissante couche d'abstraction. Même si cela peut parfois être un peu maladroit, cela facilite la synchronisation de l'interface utilisateur avec l'état.
• Les performances de SPA sont très médiocres et le Web présente de nombreuses limitations supplémentaires que les applications natives n'ont pas. Nous devons publier tout le code sur le Web, l'avoir en JIT, puis l'exécuter pour lancer notre application pendant que l'application locale a été téléchargée et compilée, ce qui est une tâche ardue.
• En tant que langage, JavaScript présente de nombreux problèmes et il doit vraiment être amélioré pour améliorer les choses - les frameworks ne peuvent pas y parvenir seuls.
• Nous avons définitivement besoin de meilleurs outils de création, modules et packaging pour écrire des applications à grande échelle.

Dans l’ensemble, cette époque est productive. Malgré les inconvénients, à mesure que la complexité de l'application augmente, les avantages du découplage du client de l'API sont énormes et, dans de nombreux cas, l'expérience utilisateur qui en résulte est étonnante. Sauf circonstances particulières, cette époque pourrait perdurer, et nous réitérons toujours les idées de style MV*.

Mais ensuite, un astéroïde est soudainement apparu, brisant le paradigme existant, provoquant un événement d'extinction à petite échelle et nous poussant dans l'ère suivante - cet astéroïde s'appelle React.

Couche de vue centrée sur les composants

Je ne pense pas que React ait inventé les composants, mais pour être honnête, je ne sais pas d'où ils viennent. Mais cela remonte au moins au XAML dans .NET, et c'est à ce moment-là que les composants Web ont commencé à évoluer en tant que spécification. En fin de compte, cela n’avait pas d’importance : une fois l’idée apparue, tous les principaux cadres l’ont adoptée très rapidement.

Avec le recul, cela est tout à fait logique : étendre le HTML, réduire l'état de longue durée, lier la logique métier JS directement aux modèles (qu'il s'agisse de JSX, de guidons ou de directives).

Les applications basées sur des composants suppriment la plupart des abstractions nécessaires pour accomplir le travail et simplifient considérablement le cycle de vie du code : tout est lié au cycle de vie du composant plutôt qu'à celui de l'application, ce qui signifie qu'en tant que développeur, vous avez beaucoup moins de choses à penser. à propos de.

Cependant, il y a eu aussi un changement à cette époque : les frameworks ont commencé à se présenter comme des « couches de vues » plutôt que comme des frameworks à part entière. Au lieu de résoudre tous les problèmes requis par les applications frontales, ils se concentrent sur la résolution des problèmes de rendu.

D'autres problèmes, tels que le routage, la communication API et la gestion de l'état, sont laissés à la discrétion de l'utilisateur. Les frameworks célèbres de cette époque sont :

1. React.js
2. Vue.js
3. Svelte
4. Polymer.js

et bien d'autres. Avec le recul, je pense qu'il s'agissait d'un framework populaire parmi les frameworks de deuxième génération car il faisait en réalité deux choses principales.

• Cela réduit considérablement la portée. Plutôt que d’essayer de résoudre tous ces problèmes dès le départ, le cœur du cadre se concentre sur le rendu, et de nombreuses idées et orientations différentes peuvent être explorées pour d’autres fonctionnalités au sein d’un écosystème plus large. Il existe de nombreuses mauvaises solutions, mais il existe également de bonnes solutions, ouvrant la voie à la prochaine génération pour qu’elle choisisse les meilleures idées parmi la crème.
• Cela nous permet de les accepter plus facilement. Adopter un framework complet pour reprendre l'intégralité de votre page Web signifie réécrire la majeure partie de votre application, ce qui n'est pas possible avec les monolithes côté serveur existants. À l'aide de frameworks tels que React et Vue, vous pouvez en déposer de petites portions dans des applications existantes, un widget ou un composant à la fois, permettant aux développeurs de migrer progressivement leur code existant.

Ces deux facteurs ont conduit au développement rapide des frameworks de deuxième génération, éclipsant les frameworks de première génération, de loin, tout semble logique et constitue une évolution raisonnable. Mais y être à l’époque était une expérience assez frustrante.

Tout d'abord, lorsque nous débattons du framework à utiliser au travail, ou si nous devons réécrire notre application, nous ne rencontrons pas souvent un tel framework. Au lieu de cela, c'est souvent « C'est plus rapide ! » ou « C'est plus petit ! » ou « C'est tout ce dont vous avez besoin ! ».

Il y a aussi le débat sur la programmation fonctionnelle et la programmation orientée objet, avec de nombreuses personnes désignant la FP comme la solution à tous nos problèmes. Pour être honnête, ces choses sont vraies. Les cadres de calque d'affichage uniquement sont plus petits (au début), plus rapides (au début) et suffisent (si vous construisez ou cousez beaucoup de choses vous-même).

Bien sûr, les modèles de programmation fonctionnelle résolvent de nombreux problèmes qui affectent JavaScript, et je pense qu'en moyenne, JS est meilleur grâce à eux.

Cependant, la réalité est qu’il n’existe pas de solution miracle. Les applications sont encore volumineuses, volumineuses et complexes, l'état est toujours difficile à gérer et des problèmes fondamentaux tels que le routage et le SSR doivent encore être résolus.

Pour beaucoup d'entre nous, ce que les gens semblent vouloir, c'est abandonner la solution qui tente de résoudre tous ces problèmes et la remplacer par une solution qui laisse les lecteurs le découvrir par eux-mêmes.

D'après mon expérience, c'est également une pratique courante parmi les groupes d'ingénierie qui accepteront volontiers ce changement afin de proposer un nouveau produit ou une nouvelle fonctionnalité et ne financeront ensuite pas le temps nécessaire au développement complet de toutes ces fonctionnalités supplémentaires.

Le résultat est des frameworks faits maison construits autour de ces couches de vues, qui sont elles-mêmes volumineuses, complexes et extrêmement difficiles à utiliser.

Je pense qu'une grande partie des problèmes que les gens rencontrent avec le SPA proviennent de cet écosystème fragmenté, qui est apparu au moment même où l'utilisation du SPA explose. Je tombe encore souvent sur un nouveau site Web qui n'effectue pas correctement le routage ou ne gère pas bien d'autres petits détails, et c'est absolument frustrant.

Mais d'un autre côté, le cadre de service complet de première génération existant ne fait pas un très bon travail pour résoudre ces problèmes. Cela est dû en partie à un important bagage de dettes techniques. Les frameworks de première génération ont été construits avant ES6, avant les modules, avant Babel et Webpack, avant que nous ayons compris beaucoup de choses.

L'évolution itérative est très difficile, et les réécrire complètement, comme Angular l'a fait avec Angular 2, tue l'élan de leur communauté.

Les développeurs sont donc confrontés à un dilemme en ce qui concerne les frameworks JavaScript : soit choisir une solution tout-en-un qui commence à montrer son âge, soit se lancer dans la moitié libre et DIY du framework et espérer le meilleur.

C'était très frustrant à l'époque, mais cela a fini par produire beaucoup d'innovation. L'écosystème JavaScript a évolué très rapidement et un certain nombre d'autres changements clés se sont produits à mesure que ces frameworks découvrent leurs meilleures pratiques.

• Les transpilateurs comme Babel deviennent la norme et contribuent à moderniser le langage. Plutôt que d’attendre des années pour que les fonctionnalités soient standardisées, elles peuvent être utilisées aujourd’hui, et le langage lui-même commence à ajouter des fonctionnalités à un rythme plus rapide et plus itératif.
• Les modules ES ont été standardisés afin que nous puissions enfin commencer à créer des outils de construction modernes autour d'eux, comme Rollup, Webpack et Parcel. Le regroupement basé sur l'importation devient peu à peu la norme, même pour les ressources non-JS telles que les styles et les images, ce qui simplifie grandement la configuration des outils de construction, les rendant plus simples, plus rapides et plus complets.
• À mesure que de plus en plus d'API sont standardisées, l'écart entre les standards Node et Web se réduit lentement mais régulièrement. Le SSR a commencé à devenir une possibilité réelle, puis quelque chose que toutes les applications sérieuses faisaient, mais à chaque fois il s'agissait d'une configuration personnalisée.
• Edge Computing est lancé, offrant aux applications serveur basées sur JavaScript les avantages du temps de distribution/réponse du SPA (les spas commençaient auparavant généralement à se charger plus rapidement en raison du fait qu'ils étaient des fichiers statiques sur le CDN, même s'ils mettaient plus de temps à se charger complètement et à se terminer).

A la fin de cette époque, certaines questions demeurent encore. La gestion de l’État et la réactivité étaient (et sont toujours) des questions épineuses, même si nous disposons de meilleurs modèles qu’avant.

La performance reste une question difficile et même si les choses s'améliorent, il existe encore de très nombreux SPA gonflés.

La situation de l'accessibilité s'est également améliorée, mais pour de nombreuses organisations d'ingénierie, cela reste souvent une réflexion après coup. Mais ces changements ont ouvert la voie à la prochaine génération de cadres, dans laquelle je dirais que nous entrons maintenant.

Framework full stack

Personnellement, la dernière ère du framework est arrivée très discrètement. Je pense que c'est parce que j'ai passé les 4 dernières années environ à creuser les composants internes de la couche de rendu d'Ember, en essayant de résoudre la dette technique susmentionnée qui l'affectait (encore) en tant que framework de première génération. Mais c'est aussi parce que c'est plus subtil, parce que tous ces frameworks de troisième génération sont construits autour des frameworks de couche de vue de la génération précédente. Ces frameworks incluent :

1. Next.js (React)
2. Nuxt.js (Vue)
3. Remix (React)
4. SvelteKit (Svelte)
5. Gatsby (React)
6. Astro (Any)

Tout a commencé avec la maturité et la consolidation de la couche vue. Maintenant que nous sommes tous d'accord sur le fait que les composants sont construits au-dessus du noyau, il est logique de commencer à standardiser d'autres parties de l'application - les routeurs, les systèmes de construction, les structures de dossiers, etc.

Lentement, ces méta-frameworks commencent à créer les mêmes fonctionnalités que les solutions tout-en-un de première génération, en sélectionnant les meilleurs modèles de leurs écosystèmes respectifs et en les incorporant à mesure qu'ils mûrissent.

Puis ils sont allés encore plus loin.

Avant cela, SPA se concentrait uniquement sur le client. SSR est quelque chose que chaque framework veut résoudre, mais uniquement en tant qu'optimisation, moyen d'être rendu et finalement remplacé lorsque les mégaoctets de JS sont enfin chargés.

Un seul framework de première génération a osé penser plus loin, Meteor.js, mais son idée de JS isomorphe ne s'est jamais vraiment concrétisée.

Mais à mesure que la taille et la complexité de l’application augmentent, l’idée est revisitée.

Nous avons remarqué qu'il est en fait très utile de coupler le backend et le frontend afin que vous puissiez faire des choses comme masquer les secrets de l'API pour certaines requêtes, modifier les en-têtes lors du retour des pages et les requêtes API proxy. Alors que Node et Deno implémentent de plus en plus de standards Web et que l'écart entre JS côté serveur et JS côté client se réduit chaque année, il commence à sembler que ce n'est pas une idée si folle après tout. Combinez cela avec l’informatique de pointe et des outils incroyables, et vous obtenez un potentiel incroyable.

La dernière génération de frameworks tire pleinement parti de ce potentiel, mélangeant client et serveur de manière transparente, et je ne peux pas souligner à quel point cela est incroyable. Au cours des 9 derniers mois de travail avec SvelteKit, je ne sais pas combien de fois je me suis assis et je me suis dit : « C'est ce que nous devrions faire tout le temps

Voici quelques-unes des tâches que j'ai effectuées. » J'ai rencontré récemment avec cette configuration, ces tâches deviennent incroyablement faciles.

• Ajout d'OAuth côté serveur à notre application afin que le jeton d'authentification ne quitte jamais le serveur, ainsi qu'un proxy API qui ajoute le jeton lors des requêtes à notre API.
• Proxyez certaines routes directement vers notre CDN afin que nous puissions héberger des pages HTML statiques construites dans n'importe quel autre framework, permettant aux utilisateurs de créer leurs propres pages personnalisées (un service que nous proposons à certains clients).
• Ajoutez quelques routes API uniques différentes lorsque nous devons utiliser un service externe qui nécessite une clé (pas besoin d'ajouter une toute nouvelle route à notre API et de se coordonner avec les personnes backend).
• Déplacer notre utilisation de LaunchDarkly côté serveur afin que nous puissions charger moins de JS, réduisant ainsi les coûts globaux.
• Proxyez nos requêtes Sentry via le routage backend afin que nous puissions détecter les erreurs qui ne sont pas signalées en raison des bloqueurs de publicités.

Et ce n'est que la pointe de l'iceberg. Il y a vraiment beaucoup de choses intéressantes à propos de ce modèle, dont le plus important est la façon dont il revigore l'idée d'amélioration progressive, en tirant parti des fonctionnalités combinées du serveur et du client pour permettre au client de revenir aux paramètres de base si l'utilisateur le désactive. Javascript HTML + HTTP.

Quand j'ai commencé à travailler dans les spas, j'avais moi-même complètement abandonné cette pratique pensant que c'était la tendance du futur, mais c'est vraiment cool qu'on puisse potentiellement voir un monde où elle fait son retour.

Ce sont des nouveautés. Par expérience, je classe ces frameworks comme des frameworks de nouvelle génération. Les problèmes qui étaient auparavant difficiles, voire impossibles à résoudre, deviennent désormais triviaux, ne nécessitant qu'un léger changement dans la logique de traitement des réponses.

Des performances fiables et une expérience utilisateur sont prêtes à l'emploi et ne nécessitent aucune configuration supplémentaire. Au lieu de créer un tout nouveau service, nous pouvons ajouter des points de terminaison ou des middlewares supplémentaires si nécessaire. Cela a changé ma vie.

Je pense que cette génération résout également certains des points de conflit majeurs entre les frameworks de première et deuxième génération et leurs utilisateurs.

Cela a commencé par un passage à une terminologie sans configuration, mais je pense que cela est finalement dû à la maturité et à la stabilité de l'écosystème autour des frameworks de deuxième génération, ce qui constitue également un changement culturel.

Les frameworks de troisième génération tentent désormais d'être à nouveau une solution tout-en-un, essayant de résoudre tous les problèmes fondamentaux que nous devons résoudre en tant que développeurs front-end - pas seulement le rendu.

Maintenant plus que jamais, on a l'impression que la communauté est alignée sur tous les nombreux problèmes qui affligent SPA et, plus important encore, qu'elle les résout ensemble.

Où allons-nous ensuite ?

Dans l’ensemble, je pense que la communauté JavaScript évolue dans la bonne direction. Nous avons enfin développé des solutions matures pour créer des applications complètes à partir de zéro qui ne sont pas « juste une couche de vue ».

Nous commençons enfin à rivaliser sur la même ligne de départ que les SDK d'applications natives, en fournissant une boîte à outils complète prête à l'emploi.

Nous avons encore beaucoup de travail à faire dans ce domaine. L'accessibilité a longtemps été une réflexion secondaire dans le monde SPA, et en dehors de GraphQL, je pense toujours que les histoires de données pourraient nécessiter un peu de travail (qu'on le veuille ou non, la plupart du Web fonctionne toujours sur REST).

Mais la tendance est bonne, et si nous continuons à avancer dans le sens de solutions partagées, je pense que nous pouvons résoudre ces problèmes d'une meilleure manière qu'auparavant.

Je suis également enthousiasmé par le potentiel qui existe derrière l’intégration de ces modèles dans la plate-forme Web elle-même. Les composants Web continuent d'être itérés en silence, travaillant sur des problèmes tels que SSR et supprimant l'enregistrement global, ce qui les rendra plus compatibles avec ces frameworks de troisième génération.

Dans l'autre sens, WebAssembly peut itérer sur ce modèle d'une manière incroyable. Imaginez pouvoir écrire un framework full-stack dans n'importe quel langage.

Les langages isomorphes comme Rust, Python, Swift, Java, etc. peuvent enfin réduire la barrière entre l'avant et l'arrière à presque zéro - juste un petit modèle HTML à la limite de votre système (ce qui, ironiquement, nous fait presque contourner le cercle, mais avec une meilleure expérience utilisateur).

Mon plus grand espoir ici est que nous dépassions chaque jour l'ère de la fragmentation et l'ère des nouveaux frameworks JS. La liberté et la flexibilité engendrent l’innovation, mais elles conduisent également à des expériences déroutantes, déconnectées et souvent fondamentalement brisées sur le Web.

Lorsque les développeurs doivent choisir entre plus de 50 options et les assembler avec des ressources limitées et des délais serrés, c'est l'expérience que nous voyons, et elle est logique. Certaines applications sont rapides, cohérentes, fiables et amusantes à utiliser, tandis que d'autres sont frustrantes, déroutantes, lentes et interrompues.

Si nous pouvions donner aux développeurs des outils plus faciles à utiliser et faisant les bonnes choses par défaut, peut-être que les sites Web en général seraient meilleurs et que l'expérience en général serait plus fluide.

Cela ne réparera pas tous les sites Web – aucune quantité de code ne peut corriger une mauvaise conception UX. Mais cela établira une base commune, de sorte que chaque site Web démarre un peu mieux et que chaque développeur ait plus de temps pour se concentrer sur autre chose.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!