Implications de la pensée en blocs au lieu de blobs

Gutenberg est un éditeur basé sur JavaScript (plus précisément, c'est un éditeur basé sur React), qui transformera bientôt l'expérience de création de contenu pour WordPress et (sur une prochaine étape lorsque Gutenberg sera transformé en constructeur de site) l'expérience de création Sites WordPress.

Gutenberg, le constructeur du site, exigera une façon différente de penser comment jeter les bases d'un site Web. Dans ce que nous pouvons déjà appeler l'"ancien" modèle, les sites WordPress sont créés en donnant une structure à travers des modèles ( header.php , index.php , sidebar.php , footer.php ), et en récupérant le contenu de la page à partir d'un seul blob de code HTML. Dans le nouveau modèle, la page comporte des composants (React) placés sur toute la page, chacun contrôlant sa propre logique, chargeant ses propres données et s'auto-affichant.

Pour apprécier visuellement le changement à venir, WordPress passe de ceci :

…pour ça:

Je pense que passer de blocs de code HTML à des composants pour les sites de construction n'est rien de moins qu'un changement de paradigme. L'impact de Gutenberg est bien plus qu'un passage de PHP à JavaScript : il y a des choses qui pourraient être faites dans le passé qui n'auront peut-être plus de sens. De même, un nouveau monde de possibilités s'ouvre, comme des interactions utilisateur riches et puissantes. Les développeurs Web ne passeront pas de la création de leurs sites dans une langue à la création de leurs sites dans une autre langue car le site ne sera plus le même ; ce sera un tout autre site qui sera construit.

Lecture recommandée : L'anatomie complète de l'éditeur WordPress de Gutenberg

Gutenberg n'a pas encore été pleinement adopté par la communauté WordPress, pour de nombreuses raisons. D'une part, la nouvelle architecture est basée sur une pléthore d'outils et de technologies (React, NPM, Webpack, Redux, etc.) qui est beaucoup plus difficile à apprendre et à maîtriser que l'ancienne basée sur PHP. Et bien qu'il puisse valoir la peine d'apprendre une nouvelle pile qui offre de nouvelles fonctionnalités, tous les sites mom & pop n'ont pas besoin de ces nouvelles fonctionnalités brillantes.

Après tout, ce n'est pas un hasard si 30% de tous les sites à travers le monde sont des sites WordPress : la plupart d'entre eux sont des sites vraiment simples tels que des blogs, et non des réseaux sociaux dynamiques comme Facebook. D'autre part, l'inclusivité de WordPress signifie que n'importe qui peut créer un site Web simple, même les personnes sans expérience en codage, telles que les concepteurs, les spécialistes du marketing de contenu et les blogueurs.

Mais la complexité de la nouvelle architecture laissera de côté de nombreuses personnes (je ne veux même pas penser à déboguer mon site en code JavaScript minifié). Et d'autre part, une fois que Gutenberg sera mis en ligne, React, soutenu par Facebook, sera ajouté à 30 % de tous les sites Web dans le monde - du jour au lendemain. Beaucoup de gens sont mal à l'aise de donner autant de pouvoir à n'importe quel type de bibliothèque JavaScript, tandis que beaucoup d'autres se méfient de Facebook. Pour atténuer cette préoccupation, Gutenberg résume React pour permettre également le codage dans d'autres frameworks ou bibliothèques ; cependant, en pratique, React sera sans aucun doute la bibliothèque JavaScript prédominante.

Et pourtant, la perspective de se voir offrir un nouveau monde de possibilités est vraiment douce. Dans mon cas, je suis ravi. Cependant, mon enthousiasme ne concerne pas la technologie (React) ou la mise en œuvre (Gutenberg), mais le concept, qui consiste à créer des sites utilisant des composants comme unité de construction. À l'avenir, l'implémentation pourrait passer à une autre plate-forme, telle que Vue, mais le concept restera.

Prévoir quelles nouvelles fonctionnalités nous pourrons implémenter n'est pas toujours facile. Il faut du temps pour s'adapter à un nouveau paradigme, et nous avons tendance à utiliser de nouveaux outils à l'ancienne jusqu'à ce que nous sachions comment utiliser les nouveaux outils pour atteindre de nouveaux objectifs. Même les fichiers PDF (qui sont une représentation de l'impression, la technologie prédominante avant la naissance du Web) sont encore monnaie courante sur le Web, négligeant les avantages du Web par rapport à l'impression.

"Imiter le papier sur un écran d'ordinateur, c'est comme arracher les ailes d'un 747 et l'utiliser comme bus sur l'autoroute."

—Ted Nelson

Dans cet article, j'analyserai plusieurs implications de la construction de sites via une architecture basée sur des composants (en tant que concept) et via Gutenberg (en tant que mise en œuvre), y compris les nouvelles fonctionnalités qu'il peut offrir, à quel point il peut mieux s'intégrer au développement actuel du site Web. tendances et ce que cela signifie pour l'avenir de WordPress.

Polyvalence étendue et disponibilité du contenu

Un effet secondaire très important du traitement de tout le contenu comme des blocs est qu'il permet de cibler des morceaux de HTML individuellement et de les utiliser pour différentes sorties. Alors que le contenu inséré dans le blob HTML n'est accessible que via la page Web, en tant que morceaux, il est accessible via une API et ses métadonnées sont facilement disponibles. Prenez des éléments multimédias - tels que des vidéos, de l'audio ou des images. En tant que bloc autonome, la vidéo peut être lue dans une application, l'audio peut être lu sous forme de podcast et les images peuvent être jointes à l'e-mail lors de l'envoi d'un résumé - tout cela sans avoir à analyser le code HTML.

De même, le contenu des blocs peut être adapté à différents supports : du plus petit écran au plus grand, tactile ou de bureau, commandé par la voix ou par le toucher, 2D/AR/VR, ou qui sait ce que l'avenir nous réserve. Par exemple, un bloc audio permet à l'audio d'être lu sur une Apple Watch, commandé par la voix via le système embarqué ou un AWS Echo, ou en tant qu'élément flottant dans notre monde virtuel lors de l'utilisation d'un casque VR. Les blocs peuvent également faciliter la configuration d'une source unique de vérité pour le contenu à publier dans différentes sorties, telles qu'un site Web réactif, AMP, application mobile, e-mail ou tout autre, comme cela a été fait par NPR via leur Create Once , approche Publier Partout (COPE).

Note : Pour plus d'informations sur ces sujets, je vous suggère de regarder la conférence Content in a Zombie Apocalypse de Karen McGrane.

Les blocs peuvent également améliorer l'expérience utilisateur. Si vous naviguez sur le site via la 3G, les blocs peuvent s'auto-afficher en mode de connexion lente pour afficher des images de mauvaise qualité et ignorer le chargement des vidéos. Ou il peut améliorer la mise en page, comme proposer d'afficher une galerie d'images en un clic à n'importe quel endroit de la page Web, et pas seulement à l'endroit où elle a été intégrée dans l'article.

Ces expériences peuvent être atteintes en séparant le contenu de la forme, ce qui implique que la présentation et le sens du contenu sont découplés, et seul le sens est enregistré dans la base de données, rendant les données de présentation secondaires et les enregistrant à un autre endroit. Le HTML sémantique est une expression de ce concept : nous devrions toujours utiliser <em> qui implique le sens, au lieu de <i> qui est une forme de présentation (pour faire afficher le caractère en italique), car alors ce contenu sera disponible pour d'autres médiums, tels que la voix (Alexa ne peut pas lire en italique, mais elle peut mettre l'accent sur la phrase).

Il est très difficile d'obtenir une séparation complète du contenu de la forme car le code de présentation sera souvent ajouté à l'intérieur du bloc, via le balisage HTML (l'ajout de la classe "pull-right" implique déjà la présentation). Cependant, l'architecture du site à l'aide de blocs permet déjà d'atteindre un certain niveau de séparation au niveau de la mise en page. De plus, les blocs créés pour faire une seule chose, et le font très bien, peuvent utiliser le bon HTML sémantique, avoir une bonne séparation des préoccupations dans sa propre architecture concernant HTML, JS et CSS (afin que les porter sur d'autres plates-formes peut nécessiter un minimum d'effort) et être accessible, au moins au niveau des composants.

Note : Une règle générale : plus un composant est inclusif, plus il est préparé pour des médiums encore à inventer.

Malheureusement, Gutenberg n'a pas été conçu dans ce but, donc les blocs contiennent également beaucoup de balisage HTML pour la présentation. Par exemple, un bloc d'image d'une image externe n'a pour signification que l'URL de l'image, la description alt et la légende (et éventuellement aussi la largeur et la hauteur) ; après avoir créé un bloc d'image, le morceau de code suivant a été enregistré dans la base de données (la classe aligncenter est destinée à la présentation, et le balisage <div class="wp-block-image" /> serait complètement redondant s'il ne stockait que la signification) :

 <!-- wp:image {"align":"center"} --> <div class="wp-block-image"> <figure class="aligncenter"> <img src="https://cldup.com/cXyG__fTLN.jpg" alt="Beautiful landscape"/> <figcaption>If your theme supports it, you'll see the "wide" button on the image toolbar. Give it a try.</figcaption> </figure> </div> <!-- /wp:image -->

De plus, les blocs sont enregistrés dans le contenu de la publication (qui est un gros blob HTML) au lieu que chacun ait sa propre entrée dans la base de données. Les blocs réutilisables (également appelés blocs globaux) ont cependant leur propre entrée, ce qui me fait craindre que les développeurs puissent convertir des blocs standard en blocs réutilisables juste pour un hack rapide pour y accéder directement dans la base de données.

De même, je crains que, s'ils ne sont pas correctement conçus, les blocs puissent même causer des ravages sur nos sites. Par exemple, les développeurs ignorants peuvent ignorer la règle de la moindre puissance, en utilisant JavaScript non seulement pour les fonctionnalités, mais aussi pour le CSS et le balisage. De plus, la fonctionnalité de rendu côté serveur (SSR) de Gutenberg n'est pas isomorphe (c'est-à-dire qu'elle ne permet pas à une seule base de code de produire la sortie pour le code côté client et côté serveur), par conséquent, les blocs dynamiques doivent implémenter la fonction pour générer le code HTML également en tant que PHP pour offrir une amélioration progressive (sans laquelle le site est inaccessible lors de son chargement initial).

En résumé, les blocs sont un pas dans la bonne direction pour rendre le contenu WordPress disponible sur n'importe quel format et pour n'importe quel support, mais ils ne sont pas une solution définitive, tant de travail reste à faire.

Performance

Les performances comptent. Des sites plus rapides conduisent à des utilisateurs plus heureux, ce qui conduit à de meilleurs taux de conversion. L'équipe d'Etsy, par exemple, propose de nouvelles fonctionnalités, aussi cool soient-elles, si elles font passer le temps de chargement de leur site au-dessus d'un seuil critique (je recommande de regarder la conférence d'Allison McKnight sur la construction de performances à long terme et les diapositives), tandis que l'équipe de Twitter a repensé son site il y a plusieurs années pour prendre en charge le rendu côté serveur afin d'afficher le contenu dès que possible, et implémente continuellement de nombreux petits changements qui s'additionnent pour offrir une expérience utilisateur rapide.

JavaScript étant si attractif pour les développeurs, ils n'éprouvent aucune contrainte sur leur utilisation, ce qui est un vrai problème : JavaScript est très coûteux en performances, et il doit être utilisé avec beaucoup de précautions.

Dans l'état actuel des choses, Gutenberg est loin d'être optimal : alors que la création d'un article avec l'ancien éditeur (pour lequel nous devons installer l'éditeur classique) nécessite de charger environ 1,4 Mo de JavaScript, Gutenberg charge environ 3,5 Mo de JavaScript, rien que pour son fonctionnement de base. expérience (c'est-à-dire sans installer de bloc supplémentaire):

Cela signifie que, dans l'état actuel des choses, 3,5 Mo constituent la base de référence et que la taille de chargement ne fera qu'augmenter à partir de là, à mesure que l'administrateur du site installe davantage de blocs. Comme on l'a vu dans un article récent sur Smashing Magazine, la création d'un bloc de témoignages nécessitait 150 Ko de JavaScript minifié. Combien de blocs un site standard nécessitera-t-il ? Combien de Mo de JavaScript un site moyen devra-t-il télécharger ?

Les implications sont multiples : d'une part, un site lourd est hors de portée du prochain milliard d'utilisateurs, qui y ont accès principalement sur des connexions lentes, et qui achètent des forfaits de données qui représentent une part importante de leur salaire. Pour eux, chaque Mo de données fait une différence : envoyer des messages Whatsapp est abordable, télécharger plusieurs Mo de scripts juste pour charger un site ne l'est pas.

Il est vrai que l'utilisateur du site Web n'aura pas besoin d'interagir avec Gutenberg, puisque Gutenberg est simplement pour construire le site, pas pour l'utiliser : Gutenberg est un éditeur back-end, pas un éditeur front-end (et il ne peut jamais être - au moins dans le cadre du noyau WordPress). Cependant, les créateurs de contenu seront pénalisés, et ils constituent déjà une cible de taille. De plus (comme je l'ai expliqué précédemment), les utilisateurs peuvent également être pénalisés par des blocs dynamiques, qui peuvent créer leur balisage via JavaScript côté client au lieu de PHP côté serveur.

Il y a aussi le problème du gonflement des fonctionnalités dupliquées ajoutées par des plugins tiers. Autrefois, un site WordPress pouvait avoir chargé plusieurs versions de jQuery, ce qui était relativement facile à corriger. De nos jours, il existe une vaste gamme de bibliothèques open source parmi lesquelles choisir pour implémenter une fonctionnalité nécessaire (glisser-déposer, calendriers, composants à sélection multiple, carrousels, etc.), il est donc plus probable qu'improbable un site avec des dizaines de blocs tiers aura la même fonctionnalité implémentée par différentes bibliothèques, créant un gonflement inutile. De plus, il y a un peu de gonflement ajouté à Gutenberg lui-même : parce que les blocs sont enregistrés dans le frontend, la désinscription d'un bloc déjà enregistré se fait en chargeant un script supplémentaire. À mon avis, c'est l'un des plus grands défis pour les contributeurs de Gutenberg : mettre en place un processus rationalisé qui permet à quiconque (pas seulement aux développeurs expérimentés avec Webpack) de supprimer les bibliothèques indésirables et de ne regrouper que l'ensemble minimal de ressources nécessaires à l'application. .

Enfin, je mentionne à nouveau que Gutenberg prend en charge le rendu côté serveur, mais comme il n'est peut-être pas facile à maintenir, les développeurs peuvent être tentés de ne pas s'y fier. Dans ce cas, il y a le coût des allers-retours supplémentaires nécessaires pour obtenir les données des points de terminaison REST, juste pour rendre la mise en page, pendant laquelle l'utilisateur attendra.

À mon avis, la performance sera l'un des défis majeurs pour Gutenberg, celui qui pourrait faire ou défaire en termes d'adoption généralisée, et il reste encore beaucoup de travail à faire, ciblant principalement la prochaine étape lorsque Gutenberg deviendra un site constructeur.

Normes Web

Comme mentionné précédemment, Gutenberg résume React pour fournir une approche indépendante du cadre des blocs de construction qui, s'ils sont correctement mis en œuvre, peuvent éviter que WordPress ne soit verrouillé sur React. La communauté WordPress est prudente lors de la fusion de n'importe quel framework JavaScript dans le noyau WordPress, en grande partie parce que Backbone.js, peu de temps après avoir été ajouté au noyau WordPress, a connu une forte baisse de popularité, et à part alimenter le gestionnaire de médias, peu de fonctionnalités ont été accomplies. avec ça. Même si React est la bibliothèque JavaScript la plus populaire à l'heure actuelle, il n'y a aucune raison de croire que ce sera toujours le cas (comme le dénouement de jQuery peut en témoigner), et WordPress doit être préparé pour le moment où ce jour arrivera enfin (ce qui, compte tenu de la rapidité rythme de la technologie, peut arriver plus tôt que prévu).

La meilleure façon d'éviter d'être verrouillé sur une bibliothèque est d'utiliser les normes Web et, plus précisément dans ce cas, l'implémentation de blocs via des composants Web. Les composants Web sont des composants fortement encapsulés qui fonctionnent avec les API du navigateur, ils ne nécessitent donc aucune bibliothèque JavaScript pour fonctionner. Cependant, ils peuvent être implémentés via n'importe quel framework JavaScript côté client.

Même si React ne fournit pas encore une intégration transparente avec les composants Web, cela finira (ou plutôt, espérons-le) par le faire. Comme expliqué dans la documentation de React, les composants Web et les composants React peuvent fonctionner parallèlement :

« React et les composants Web sont conçus pour résoudre différents problèmes. Les composants Web fournissent une encapsulation solide pour les composants réutilisables, tandis que React fournit une bibliothèque déclarative qui maintient le DOM synchronisé avec vos données. Les deux objectifs sont complémentaires. En tant que développeur, vous êtes libre d'utiliser React dans vos composants Web, ou d'utiliser des composants Web dans React, ou les deux.

À ce jour, les perspectives que cette situation se produise ne semblent pas très prometteuses : je n'ai trouvé aucun didacticiel pour les blocs de construction avec des composants Web. Je pense que la communauté devrait concentrer ses efforts sur cette cause, en encourageant les développeurs à commencer à construire des blocs à l'aide de composants Web, et le plus tôt sera le mieux, car Gutenberg nous oblige à apprendre de nouvelles technologies de toute façon, dès maintenant. C'est l'occasion d'établir une base solide avec les standards du web, dès le début.

Interopérabilité entre les sites, homogénéisation des sites

Un bloc est une entité plus petite qu'un thème ou un plugin, donc les blocs seront éventuellement accessibles seuls et acquis via des marchés de blocs nouvellement créés. Il y aura très probablement dans un premier temps une explosion cambrienne de blocs alors que de nombreux acteurs de l'écosystème se précipitent pour être les premiers à commercialiser leurs solutions, menant à moyen et long terme vers la consolidation des plus performantes.

Une fois la poussière retombée, quelques blocs se démarqueront et deviendront les gagnants, obtenant la majeure partie du marché dans leurs catégories spécifiques. Si/quand cela se produit sera une cause à la fois d'inquiétude et de jubilation : inquiétude concernant une nouvelle vague d'homogénéisation du Web (comme cela s'est produit avec Bootstrap), car les sites utilisant les mêmes composants peuvent se retrouver avec le même aspect et la même sensation , une jubilation sur une interopérabilité accrue entre les sites en s'appuyant sur les mêmes composants et les mêmes API, ce qui peut ouvrir les portes à de nouvelles opportunités.

Je suis particulièrement enthousiaste à l'idée d'étendre l'interopérabilité entre les sites. C'est un domaine qui pourrait, à long terme, défaire des royaumes comme celui de Facebook : au lieu de s'appuyer sur une passerelle monopolistique pour partager des informations, les sites avec différentes communautés peuvent facilement partager des données entre eux, directement. Ce n'est pas un nouveau concept : le mouvement IndieWeb travaille depuis longtemps pour permettre à chacun de posséder ses propres données sur ses propres serveurs, en faisant parler les sites Web entre eux via des microformats. Par exemple, leur standard Web Webmention permet à deux sites d'avoir une conversation, dans laquelle chaque commentaire et réponse est stocké dans les deux, et Micro.blog propose une sorte de Twitter, mais basé sur le Web ouvert, dans lequel les messages sur la chronologie de l'utilisateur sont recueillies à partir des flux RSS et JSON des sites abonnés. Ces efforts sont merveilleux, mais leur impact reste très faible, car il faut un certain niveau de maîtrise de la technologie pour en faire partie. L'architecture basée sur les composants de Gutenberg peut potentiellement produire un impact beaucoup plus large : les blocs populaires peuvent permettre à des dizaines de sites WordPress de se parler, permettant finalement jusqu'à 30 % de tous les sites sur le Web de faire partie d'un réseau décentralisé et faiblement couplé. .

Cette zone nécessitera cependant beaucoup de travail avant d'être viable. Je ne pense pas que les points de terminaison REST par défaut soient la meilleure interface de communication car ils n'ont pas été conçus à cet effet (les gens de micro.blog ont proposé une meilleure solution via leur interface JSON, qui est basée sur la spécification RSS). De plus, REST est lui-même rendu obsolète par GraphQL, donc je ne placerais pas de grands espoirs dessus à long terme. Je suis également impliqué dans la recherche d'un meilleur moyen, pour lequel je travaille actuellement sur un autre type d'API, qui peut récupérer toutes les données requises en une seule requête, et prend en charge l'extensibilité via une architecture à base de composants.

Je m'attends également à ce que l'intégration avec les services cloud soit plus importante, car les fournisseurs peuvent libérer leurs propres blocs pour interagir avec leurs propres services. Parce qu'un composant est une unité autonome, le simple fait de glisser-déposer le bloc dans la page fait déjà tout le travail du point de vue de l'utilisateur, ce qui facilite la création de sites Web puissants avec peu ou pas de connaissances. Par exemple, un fournisseur de stockage d'images comme Cloudinary pourrait publier un bloc qui recadre automatiquement l'image en fonction de la fenêtre d'affichage de l'appareil, ou demande l'image en tant que WebP si elle est prise en charge, ou d'autres cas d'utilisation.

En résumé, la consolidation du marché des blocs peut apporter une homogénéisation de son apparence, ce qui serait un événement regrettable et devrait être évité, et de puissantes capacités concernant l'interopérabilité et le partage de données entre les sites et l'intégration avec les services cloud.

Intégration avec les bibliothèques de modèles

Une bibliothèque de modèles est une collection d'éléments de conception d'interface utilisateur, chacun d'entre eux étant souvent composé d'extraits de code HTML, JS et CSS. Un bloc est un composant autonome, souvent composé de morceaux de HTML, JS et CSS. Les blocs sont donc bien adaptés pour être documentés/construits avec des bibliothèques de modèles. Avoir des blocs expédier leurs bibliothèques de modèles serait une bonne affaire car cela pourrait permettre aux équipes de ne pas commencer à implémenter la bibliothèque de modèles du site uniquement au niveau du site, mais en tant qu'agrégation et raffinement des bibliothèques de mini-modèles de tous les blocs requis.

Je pense que quelque chose de similaire au processus de rationalisation pour produire des packages JavaScript sans ballonnement que j'ai mentionné plus tôt se produit dans ce cas, mais concernant UI/UX/Documentation. Ce serait à la fois un défi et une opportunité pour les contributeurs de Gutenberg de mettre en place un processus permettant aux développeurs de blocs de créer facilement des bibliothèques de modèles pour leurs blocs qui, une fois agrégés, peuvent aboutir à une bibliothèque de modèles cohérente pour le site. Bien implémentée, une telle fonctionnalité pourrait faire baisser les coûts des chantiers du point de vue de la documentation/maintenance.

Que va devenir WordPress ?

Gutenberg rendra certainement les sites web plus attractifs, même si au prix d'un niveau d'expertise requis que tout le monde ne pourra pas maîtriser. À plus long terme, cela peut conduire à une meilleure qualité, une quantité moindre. Venant de la maxime WordPress de "Démocratiser l'édition", cela peut devenir un problème.

Je suis enthousiasmé par Gutenberg, mais plus comme le concept d'une architecture à base de composants que pour l'implémentation basée sur React. De manière générale, je suis d'accord avec ce que Matt Mullenweg a dit lors du WordCamp Europe 2018 pour justifier Gutenberg :

« La fondation de WordPress qui nous sert désormais bien depuis quinze ans ne durera pas les quinze prochaines.

Cependant, je crois aussi que le WordPress de quinze ans dans le futur pourrait finir par être complètement différent de celui que nous connaissons aujourd'hui. Je me demande si WordPress finira par être avant tout l'éditeur basé sur le client, et pas beaucoup plus : l'initiative d'intégrer Gutenberg à Drupal, dans le but de faire de Gutenberg l'éditeur du web ouvert, officialisera WordPress comme un CMS headless opérant via les points de terminaison REST. C'est un bon développement en soi, mais cela rendra WordPress le back-end indispensable : si une autre plate-forme back-end offre de meilleures fonctionnalités, il n'y a plus aucune raison de s'en tenir au back-end WordPress. Après tout, Gutenberg côté client pourra travailler avec n'importe lequel d'entre eux, tandis que la simplicité de création d'un site avec WordPress sera perdue, nivelant le terrain de jeu avec toutes les autres plateformes.

En particulier, je ne serais pas surpris si les développeurs estiment que le maintien de deux bases de code (une en JavaScript et une en PHP) pour le rendu des blocs dynamiques est trop éprouvant, et décident de s'orienter vers des plates-formes prenant en charge le rendu isomorphe côté serveur. Si ce scénario se produit réellement, Matt déciderait-il de déplacer le backend WordPress vers Node.js ?

C'est principalement à cause de ce problème que j'ose dire que le WordPress de 15 ans peut être une entité très différente de ce qu'il est aujourd'hui. Qui sait ce qui va arriver ?

Conclusion

En faisant des composants la nouvelle unité des chantiers, l'introduction de Gutenberg transformera WordPress. Et comme pour tout changement de paradigme, il y aura des gagnants et des perdants. Différentes parties prenantes considéreront Gutenberg comme une évolution positive ou négative selon leur propre situation : si la qualité d'un site Web augmentera, le prix de la construction d'un tel site en embauchant des développeurs capables de gérer sa complexité augmentera également, ce qui le rendra moins abordable. et moins populaire.

Ce sont des moments passionnants, mais aussi des moments charnières. À partir de maintenant, WordPress peut lentement commencer à être une entité différente de celle à laquelle nous sommes habitués, et nous devrons peut-être éventuellement réfléchir à nouveau à ce qu'est WordPress et à ce qu'il représente.