Leonardo Losoviz est le créateur de PoP un framework pour la construction de sites Web modulaires basés sur PHP et les guidons, et optimisé par WordPress. Il habite à Kuala… Pour en savoir plus sur Leonardo
Qu'est-ce que Gutenberg apporte à l'avenir de WordPress? Dans cet article, Leonardo Losoviz partage un certain nombre d'implications des sites de construction via une architecture à base de composants (en tant que concept) et de Gutenberg (en tant qu'implémentation), y compris quelles nouvelles fonctionnalités il peut fournir et dans quelle mesure il peut être mieux intégré aux technologies actuelles. tendances de développement de site Web.
Gutenberg est un éditeur basé sur JavaScript (plus précisément, un éditeur basé sur React), qui transformera bientôt l'expérience de la création de contenu pour WordPress et (sur une prochaine étape lorsque Gutenberg sera transformé en constructeur de site), le expérience de la création de sites WordPress.
Gutenberg, le constructeur du site, demandera une façon différente de penser comment poser les bases d’un site Web. Dans ce que nous pouvons déjà appeler le "vieux" modèle, les sites WordPress sont créés en structurant des modèles ( header.php index.php sidebar.php footer.php ), et extraire le contenu de la page à partir d'un seul blob de code HTML. Dans le nouveau modèle, la page comporte (React) composants répartis sur toute la page, chacun contrôlant sa propre logique, chargeant ses propres données et s'auto-rendant.
Apprécier le changement à venir visuellement, WordPress évolue:
Actuellement, les pages sont créées à l'aide de modèles PHP. ( Grand aperçu )
… à ceci:
Dans un avenir proche, les pages seront construites en y insérant des composants auto-exécutables. ( Grand aperçu )
Je pense que le remplacement des blobs de code HTML par des composants pour les sites de construction est un changement de paradigme. L’impact de Gutenberg est bien plus que le 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, telles que 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 site complètement différent qui sera construit.
Gutenberg n'a pas encore été totalement adopté par la communauté WordPress, et ce pour de nombreuses raisons. D'une part, la nouvelle architecture est basée sur une multitude d'outils et de technologies (React, NPM, Webpack, Redux, etc.) beaucoup plus difficiles à apprendre et à maîtriser que l'ancien basé sur PHP. Et même s’il est intéressant d’apprendre une nouvelle pile offrant de nouvelles fonctionnalités, tous les sites mom & pop n’ont pas besoin de ces nouvelles fonctionnalités.
Après tout, ce n’est pas un hasard si 30% des sites du monde sont des sites WordPress: la plupart de ceux-ci sont des sites très simples tels que des blogs, pas 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 programmation, telles que les concepteurs, les spécialistes du marketing de contenu et les blogueurs.
Mais la complexité de la nouvelle architecture laissera de nombreuses personnes à l'écart (Je ne veux même pas penser à déboguer mon site en code JavaScript minifié). D'autre part, dès que Gutenberg sera mis en ligne, React, alimenté par Facebook, sera ajouté à 30% de tous les sites Web du monde – du jour au lendemain. Beaucoup de gens ne sont pas à l'aise de donner autant de pouvoir à une sorte de bibliothèque JavaScript, tandis que beaucoup d'autres se méfient de Facebook. Pour atténuer ce problème, Gutenberg a résumé Abstract React pour permettre également le codage dans d'autres frameworks ou bibliothèques; Cependant, dans la pratique, React constituera sans aucun doute la bibliothèque JavaScript prédominante.
Et pourtant, la perspective de se voir offrir un nouveau monde de possibilités est réellement agréable. Dans mon cas, je suis excité. Cependant, mon enthousiasme ne concerne ni la technologie (React) ni 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 peut basculer sur une autre plate-forme, telle que Vue, mais le concept restera inchangé.
Il n'est pas toujours facile de prévoir les nouvelles fonctionnalités que nous pourrons implémenter. Il faut du temps pour s'adapter à un nouveau paradigme et nous avons tendance à utiliser les nouveaux outils à l'ancienne jusqu'à ce que nous sachions comment utiliser ces nouveaux outils pour atteindre de nouveaux objectifs. Même les fichiers PDF (qui sont une représentation de l'impression, technologie prédominante avant la création du Web) sont encore courants sur le Web, négligeant ainsi les avantages du Web par rapport à l'impression.
«Imiter le papier sur un écran d'ordinateur est c'est comme déchirer les ailes d'un 747 et l'utiliser comme un bus sur l'autoroute. ” – Ted Nelson
Dans cet article, j'analyserai plusieurs implications des sites de construction grâce à une architecture à base de composants (concept). et via Gutenberg (en tant que mise en œuvre), y compris quelles nouvelles fonctionnalités il peut offrir, dans quelle mesure il peut mieux s'intégrer aux tendances actuelles du développement de sites Web et ce que cela signifie pour l'avenir de WordPress.
Polyvalence étendue et disponibilité du contenu [19659026] Un effet secondaire très important du traitement de tous les contenus en tant que blocs est qu’il permet de cibler des fragments de HTML individuellement et de les utiliser pour différentes sorties. Alors que le contenu inséré dans le blob HTML est accessible uniquement via la page Web, il est accessible aux éléments en bloc via une API et ses métadonnées sont immédiatement disponibles. Prenez des éléments multimédias – tels que des vidéos, du son 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 au courrier électronique lors de l'envoi d'un résumé, le tout sans avoir à analyser le code HTML. [19659005] De même, le contenu des blocs peut être adapté à différents supports: du plus petit écran au plus grand, écran tactile ou ordinateur de bureau, commandé par la voix ou par le toucher, 2D / AR / VR, ou qui sait ce que l'avenir peut apporter. Par exemple, un bloc audio permet de lire l'audio sur une montre Apple Watch, par commande vocale via le système embarqué ou un AWS Echo, ou comme élément flottant dans notre monde virtuel avec un casque VR. Les blocs peuvent également faciliter la configuration d'une source unique de vérité pour que le contenu soit publié dans différents résultats, tels qu'un site Web réactif, un AMP, une application mobile, un courrier électronique ou tout autre moyen, comme l'a fait NPR par le biais de leur . ] Créer une fois, publier partout (COPE)
Les blocs peuvent aussi améliorer l'expérience de l'utilisateur. Si vous naviguez sur le site en 3G, les blocs peuvent s’auto-rendre en mode de connexion lente pour afficher des images de mauvaise qualité et éviter le chargement de vidéos. Ou bien, cela peut améliorer la présentation, par exemple en proposant de montrer 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. from form, ce qui implique que la présentation et la signification du contenu sont découplées et que seule la signification est sauvegardée dans la base de données, ce qui rend les données de présentation secondaires et sauvegardées à un autre endroit. Le HTML sémantique est une expression de ce concept: nous devrions toujours utiliser ce qui implique un sens (au lieu de ), c’est une forme de présentation (pour que le caractère soit affiché en italique), car alors ce contenu sera disponible pour d'autres supports, tels que la voix (Alexa ne peut pas lire en italique, mais elle peut mettre une emphase 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 est souvent ajouté à l'intérieur du texte. block, grâce au balisage HTML (ajouter une classe «pull-right» implique déjà une présentation). Cependant, l'architecture du site à l'aide de blocs aide déjà à atteindre un certain niveau de séparation au niveau de la présentation. De plus, les blocs créés pour faire une seule chose, et le font très bien, peuvent utiliser du code HTML sémantique approprié, séparer correctement les problèmes de sa propre architecture concernant HTML, JS et CSS (afin de pouvoir les porter sur d'autres plates-formes). peut ne nécessiter qu'un effort minimal,) et être accessible, au moins au niveau du composant.
Note : Règle générale: plus un composant est inclusif, plus il est préparé c'est pour les médiums qui n'ont pas encore été inventés.
Malheureusement, Gutenberg n'a pas été conçu dans cet esprit, aussi les blocs contiennent-ils beaucoup de balises HTML pour la présentation. Par exemple, un bloc d'image d'une image externe n'a pour sens que l'URL de l'image, la description de l'alt et la légende (ainsi que éventuellement la largeur et la hauteur); après avoir créé un bloc d'image, le bloc de code suivant a été enregistré dans la base de données (la classe aligncenter est destinée à la présentation et le balisage serait complètement redondant s'il ne stockait que le sens):
Si votre thème le supporte, vous verrez le bouton "large" sur
la barre d'outils image. Essayez-le.
De plus, des blocs sont enregistrés dans le contenu de la publication (qui est un gros blob HTML) au lieu de chacun ayant une entrée distincte dans la base de données . Les blocs réutilisables (également appelés blocs globaux) ont leur propre entrée, ce qui me fait craindre que les développeurs convertissent des blocs standard en blocs réutilisables simplement pour pouvoir 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 peuvent même causer des ravages sur nos sites. Par exemple, des développeurs non conscients peuvent ignorer la règle du moindre pouvoir en utilisant JavaScript non seulement pour des fonctionnalités, mais également pour 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 à la fois pour le code client et le code côté serveur). Par conséquent, les blocs dynamiques doivent implémenter la fonction pour générer le code HTML. également comme PHP pour offrir une amélioration progressive (sans laquelle le site est inaccessible lors du 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 quel que soit le support, mais ils ne constituent pas une solution définitive, il reste encore beaucoup à faire.
Performance
La performance compte. Les sites plus rapides conduisent à des utilisateurs plus satisfaits, ce qui conduit à de meilleurs taux de conversion . L'équipe d'Etsy, par exemple, propose de nouvelles fonctionnalités, aussi cool soient-elles, si leur temps de chargement sur site dépasse un seuil critique (je recommande de regarder la conférence d'Allison McKnight sur Performance du bâtiment à long terme et diapositives ), tandis que l'équipe de Twitter a restructuré leur site il y a plusieurs années pour prendre en charge le rendu côté serveur afin d'afficher le contenu le plus rapidement possible, et met en œuvre en permanence beaucoup de petites modifications qui apportent une expérience utilisateur rapide.
Dans l’état actuel des choses, Gutenberg est loin d’être optimal: créer un poste avec l’ancien éditeur installez le Classic Editor ) nécessite environ 1,4 Mo de JavaScript, Gutenberg environ 3,5 Mo de JavaScript, uniquement pour son expérience de base (c'est-à-dire sans aucun bloc supplémentaire):
Cela signifie que, dans sa version actuelle, 3,5 Mo est la ligne de base et que la taille du chargement ne fera qu'augmenter à mesure que l'administrateur du site installera plus 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 code JavaScript simplifié. Combien de blocs un site standard nécessite-t-il?
Le nombre de Mo de JavaScript requis par un site moyen doit être téléchargé
Les implications sont multiples: pour un, un site lourd est hors de portée du prochain milliard d'utilisateurs qui ont principalement accès aux connexions lentes et qui achètent des plans de données qui représentent une part importante de leur salaire. Pour eux, chaque Mo de données fait une différence: l'envoi de messages Whatsapp est abordable, le téléchargement de plusieurs Mo de scripts simplement pour charger un site ne constitue pas un problème.
Il est vrai que l'utilisateur du site Web n'aura pas besoin d'interagir avec Gutenberg, Gutenberg est simplement un éditeur de back-end, pas un éditeur de front-end (et il se peut que ce ne soit jamais – du moins dans le cadre du noyau WordPress. Cependant, , les créateurs de contenu seront pénalisés, et ils constituent déjà une cible non négligeable. De plus, comme je l’ai déjà expliqué, les utilisateurs risquent d’être pénalisés également par le biais de blocs dynamiques, qui peuvent créer leur balise via JavaScript côté client plutôt que côté serveur. PHP.
Il existe également le problème de la duplication des fonctionnalités ajoutées par des plugins tiers.Auparavant, un site WordPress pouvait charger plusieurs versions de jQuery, ce qui était relativement facile à corriger. De nos jours, il existe une vaste gamme de libra open source Vous avez le choix entre plusieurs options pour implémenter les fonctionnalités nécessaires (glisser-déposer, calendriers, composants à sélection multiple, carrousels, etc.), de sorte qu'il est plus probable qu'un site contenant des dizaines de blocs tiers ait la même fonctionnalité implémentée par différentes bibliothèques, créant un gonflement inutile. De plus, Gutenberg lui-même est un peu gonflé: comme les blocs sont enregistrés dans le front-end, l'annulation de l'enregistrement d'un bloc déjà enregistré est effectuée en chargeant un script supplémentaire . À mon avis, c’est l’un des plus grands défis des contributeurs de Gutenberg: mettre en place un processus simplifié qui permet à tous (pas seulement aux développeurs expérimentés avec Webpack) de supprimer les bibliothèques non désirées et de ne regrouper que le minimum de ressources nécessaires à l’application.
Enfin, je mentionne encore une fois que Gutenberg prend en charge le rendu côté serveur, mais étant donné qu’il peut ne pas être facile à maintenir, les développeurs peuvent être tentés de ne pas s’en prévaloir. Dans ce cas, il y a le coût des allers-retours supplémentaires nécessaires pour obtenir les données à partir des points d'extrémité REST, uniquement pour restituer la mise en page, période pendant laquelle l'utilisateur attendra.
À mon avis, les performances seront l'un des principaux avantages Des défis pour Gutenberg, celui qui pourrait faire la différence en termes d'adoption généralisée, et il reste encore beaucoup de travail à faire, principalement pour la prochaine étape lorsque Gutenberg deviendra un constructeur de site.
Le meilleur moyen d'éviter de rester bloqué sur une bibliothèque consiste à utiliser les standards du Web et, plus précisément dans ce cas, la mise en oeuvre. de blocs à travers 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. Cependant, ils peuvent être implémentés via n’importe quel framework JavaScript côté client.
«Les composants React et 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 permet au DOM de rester 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. "
Les perspectives d’une telle situation ne sont pas très prometteuses à ce jour. été capable de trouver un tutoriel 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 à créer des blocs en utilisant des composants Web, et le plus tôt sera le mieux, puisque Gutenberg nous oblige de toute façon à apprendre de nouvelles technologies. C'est une occasion d'établir une base solide avec les standards du Web dès le tout début.
Interopérabilité entre sites, homogénéisation des sites
Un bloc est une entité plus petite qu'un thème ou un plugin; accessibles individuellement et acquises par le biais de marchés de blocs nouvellement créés . Il y aura vraisemblablement au début une explosion de blocs cambriens car de nombreux acteurs de l'écosystème se précipitent pour être les premiers à commercialiser leurs solutions, menant à moyen et long terme à la consolidation des solutions les plus performantes.
établis, 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 à la fois une source d'inquiétude et de réjouissance: une nouvelle vague d'homogénéisation du Web s'annonce (comme dans Bootstrap), car des sites utilisant les mêmes composants risquent de se retrouver avec le même aspect, une jubilation concernant une interopérabilité accrue entre sites basée sur les mêmes composants et les mêmes API, qui peut ouvrir les portes à de nouvelles opportunités.
Je suis particulièrement enthousiasmé par le développement de l'interopérabilité entre sites. C’est un domaine qui pourrait, à long terme, défaire des royaumes tels que Facebook: au lieu de s’appuyer sur une passerelle monopolistique pour le partage d’informations, les sites de différentes communautés peuvent facilement partager des données entre eux, directement. Ce n'est pas un nouveau concept: le mouvement IndieWeb s'efforce depuis longtemps de permettre à quiconque de posséder ses propres données sur ses propres serveurs, en ayant des sites web qui se parlent via des microformats. Par exemple, leur norme Web Webmention permet à deux sites d’avoir une conversation dans laquelle chaque commentaire et chaque réponse sont stockés dans les deux, et Micro.blog propose un Twitter-of- trie mais sur la base du Web ouvert, dans lequel les publications sur la timeline de l'utilisateur sont rassemblées à partir des flux RSS et JSON des sites abonnés. Ces efforts sont merveilleux, mais ont un impact très limité, car il faut un certain degré de maîtrise de la technologie pour en faire partie. L'architecture à base de composants de Gutenberg peut potentiellement avoir un impact beaucoup plus large: des blocs populaires peuvent permettre à de nombreux sites WordPress de communiquer entre eux, permettant ainsi à 30% de tous les sites Web de faire partie d'un réseau décentralisé et faiblement couplé .
Toutefois, avant d’être viable, il faudra encore beaucoup de travail dans ce domaine. Je ne pense pas que les points de terminaison REST par défaut constituent la meilleure interface de communication puisqu'ils n'ont pas été conçus à cette fin (les personnes de micro.blog ont proposé une meilleure solution via leur interface JSON qui est basée sur le RSS spécification). En outre, GraphQL rend lui-même obsolète REST, je ne mets donc pas de grands espoirs sur le long terme. Je suis également impliqué dans la recherche d'une meilleure solution pour laquelle je travaille actuellement sur un type d'API différent, capable de récupérer toutes les données requises dans une seule requête et prenant en charge l'extensibilité via une architecture à base de composants.
Je m'attends également à ce que l'intégration aux services en nuage soit plus importante, car les fournisseurs peuvent libérer leurs propres blocs pour interagir avec leurs propres services. Un composant étant une unité autonome, le simple fait de glisser-déposer le bloc dans la page effectue déjà tout le travail du point de vue de l'utilisateur, ce qui facilite grandement la création de sites Web puissants avec peu ou pas de connaissances. Par exemple, un fournisseur de stockage d'images tel que Cloudinary peut libérer un bloc qui recadre automatiquement l'image en fonction de la fenêtre d'affichage du périphérique, 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 et de son ressenti, ce qui serait un événement regrettable et devrait être évité, ainsi que de puissantes capacités en matière d'interopérabilité et de partage de données entre sites et d'intégration aux services en nuage. [19659067] Intégration aux bibliothèques de motifs
Une bibliothèque de motifs est un ensemble 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 constitué de bits HTML, JS et CSS. Les blocs conviennent donc bien pour être documentés / construits avec des bibliothèques de motifs. Avoir les blocs livrés dans leurs bibliothèques de modèles représenterait un grand avantage, car cela pourrait permettre aux équipes de ne pas commencer à mettre en œuvre la bibliothèque de modèles du site uniquement au niveau du site, mais plutôt d'agréger et d'affiner les bibliothèques de mini-modèles de tous les blocs requis. [19659005] Je crois que quelque chose de similaire au processus de rationalisation pour la production de paquets JavaScript sans bloatless dont j'ai déjà parlé se produit dans ce cas, mais concerne 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 motifs pour leurs blocs qui, une fois agrégés, peuvent donner lieu à une bibliothèque de motifs cohérente pour le site. Bien implémentée, une telle fonctionnalité pourrait réduire les coûts de construction des sites du point de vue de la documentation / de la maintenance.
Que deviendra WordPress?
Gutenberg rendra certainement les sites Web plus attractifs, même au prix du niveau requis de une expertise que tout le monde ne pourra pas gérer. À plus long terme, cela pourrait entraîner une qualité supérieure et une quantité inférieure. Venant de la maxime WordPress de «Démocratisation de l'édition», cela peut devenir un problème.
Je suis enthousiasmé par Gutenberg, mais plus par le concept d'une architecture à base de composants que par la mise en œuvre par React. De manière générale, je suis d'accord avec ce que Matt Mullenweg a déclaré lors de WordCamp Europe 2018 pour justifier Gutenberg:
"La fondation de WordPress qui nous a bien servi depuis quinze ans ne durera pas jusqu'à quinze ans . ”
Cependant, je pense aussi que WordPress (dans quinze ans) pourrait bien être complètement différent de celui que nous connaissons aujourd'hui. Je me demande si WordPress finira par être principalement l'éditeur basé sur le client, et pas beaucoup plus: l'initiative visant à intégrer Gutenberg à Drupal dans le but de faire de Gutenberg le rédacteur en chef du Web ouvert, va officialiser WordPress en tant que CMS sans tête fonctionnant via des points de terminaison REST. C’est un bon développement en soi, mais cela fera de WordPress l’arrière-plan indispensable: si une autre plate-forme d’arrière-plan offre de meilleures fonctionnalités, il n’ya aucune raison de rester fidèle à l’arrière-plan WordPress. Après tout, le client Gutenberg sera en mesure de travailler avec n'importe lequel d'entre eux, tandis que la simplicité de créer un site avec WordPress sera perdue, ce qui nivellera 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 contraignant, ils décident de basculer 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 passer du backend WordPress à Node.js?
C’est principalement à cause de ce problème que j’ose oser dire que le WordPress à partir de 15 ans pourrait être une entité très différente de ce c'est de nos jours. Qui sait ce qui va se passer?
Conclusion
En faisant des composants la nouvelle unité de construction, 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 un développement positif ou négatif en fonction de leur propre situation: alors que la qualité d’un site Web augmentera, le coût de la construction d’un tel site en recrutant des développeurs capables de gérer sa complexité augmentera également, le rendant ainsi moins abordable. et moins populaire.
Ce sont des moments excitants, mais aussi des moments cruciaux. À partir de maintenant, WordPress peut lentement devenir une entité différente de celle à laquelle nous sommes habitués, et nous aurons éventuellement besoin de réfléchir à nouveau sur ce que WordPress est et ce qu’il représente.
(rb , ra, yk, il)