Pourquoi Gutenberg est meilleur que Elementor / Divi / Beaver ?

Gutenberg est la fonctionnalité la plus prisée de WordPress dans la prochaine mise à jour 5.8 de WordPress. Auttomatic (l’équipe de WordPress) travaille dessus depuis 4 ans et malgré un soutien négligeable de la part de la communauté WordPress, WordPress continue de le pousser. Gutenberg doit être le plugin le plus redouté sur le référentiel de WordPress avec une note de 2 étoiles seulement et 300 000 utilisateurs actifs.

Alors, pourquoi diable quelqu’un voudrait-il arrêter d’utiliser Elementor / Divi / Beaver / Oxygen builder et passer à Gutenberg.

Il y a beaucoup, beaucoup de raisons de faire le changement. L’essentiel est que les constructeurs de pages ne sont tout simplement pas adaptés à la décennie 202X.

Les constructeurs de pages sont construits sur des technologies en voie de disparition

Presque tous les constructeurs de pages sont construits sur une technologie dépassée et ce n’est qu’une question de temps avant qu’ils ne disparaissent, car les nouvelles technologies peuvent faire tellement plus. Il sera vraiment difficile pour ces Page Builders de mettre à jour leur technologie car ils ont des addons et d’autres entreprises qui dépendent de leur cadre daté pour soutenir leurs plugins.

Elementor

Elementor est construit sur Marionettee et backboneJS. BackboneJS est une technologie en voie de disparition qui était à son apogée en 2013. Je ne vois pas de projet moderne utilisant backboneJS.

Comparé à reactJS sur lequel Gutenberg est construit, backbone n’a jamais pris de l’ampleur. Elementor utilise backbone dans l’écran de création de son constructeur de pages, ce qui est une bonne chose pour le moment, mais qui pose d’énormes problèmes d’interface utilisateur et manque de flexibilité. Le frontend est principalement basé sur jQuery, ce qui est un autre point que nous avons ajouté dans la liste.

Divi

Le constructeur Divi est arrivé en 2016 en utilisant le framework React 15. Le React a fait un passage à l’open source en 2016 et a publié react 16 qui est remarquablement différent du framework React 15. La doc officielle de react dit que react 16 est 3x plus rapide que react 15.

D’après mon expérience personnelle, react 16/17 est beaucoup plus simple pour construire une logique complexe et plus performant que react 15. De plus, comme Divi utilisera très probablement des modules NPM, ces modules se mettent à jour et cessent de prendre en charge les fonctionnalités obsolètes. Passer de react15 à react16 reviendrait à réécrire complètement Divi et, d’après leur documentation de développeur, tous les addons doivent être modifiés pour s’adapter à leur version mise à jour.

Beaver Builder

Le beaver builder est apparu en avril 2014 et il est basé sur jQuery. jQuery utilise des manipulations DOM (éléments HTML) pour l’animation et il est remarquablement lent par rapport à d’autres scripts, (plus de détails ci-dessous). Le beaver builder utilise un grand nombre de bibliothèques obsolètes qui non seulement augmentent la taille du site mais sont également lentes et ne conviennent pas aux événements tactiles. Ce plugin utilise également du javascript natif à certains endroits (ce qui est un point positif) mais le front-end est principalement construit en utilisant jquery.

Taille excessive des domaines

Pour aussi peu qu’un bloc divisé en 2, le HTML natif est un div et deux div enfants avec 1 ligne CSS. L’inconvénient est que la taille du DOM/page augmente beaucoup et que le navigateur prend plus de temps pour le rendu et finalement l’UX du site est lent.

Une mise en page simple : Div > Div + Div , 2 lignes seulement

Elementor

Pour cela, il faut jusqu’à 5 divisions.

Section -> Conteneur -> ligne -> enveloppe de colonne -> colonne

Divi

Il faut 5 divisions pour y parvenir.

Section -> Conteneur Row -> Row -> conteneur colonne – Column

Beaver

Il faut jusqu’à 7 divisions et il n’utilise pas le flex d’affichage pour les mises en page.

Content Wrap – Row Content – Column Group – column – column content – module – module content

Il y a une tendance ici à utiliser container, wrapper, column. Il s’agissait d’une structure populaire à l’époque de Bootstrap 3 de Twitter, c’est-à-dire au moment où ces plugins ont été lancés.

Dépendance excessive à l’égard de jQuery

jQuery est une bibliothèque créée par le légendaire “John Resig” en 2006 pour un usage personnel. Elle est devenue extrêmement populaire car elle offrait un moyen uniforme d’accéder aux éléments DOM sur les pages pour les animations et autres effets. Avance rapide en 202X, jQuery est plutôt inutile, tous les navigateurs ont maintenant un moyen uniforme d’accéder aux éléments DOM, d’exécuter du javascript complexe via des composants web et plus encore. La plupart des bibliothèques javascript modernes utilisent Shadow DOM, qui est rapide et les navigateurs ont moins de difficultés à les rendre. [ ? ]

De plus, les mobiles à écran tactile sont apparus après jQuery, donc jQuery a été modifié pour ajouter le support tactile car il n’était pas construit de manière native. Vous trouverez donc de nombreux scripts jQuery ne supportant pas les événements tactiles.

Par ailleurs, la grande majorité des scripts jQuery lisent l’événement “Document Read”, ce qui signifie qu’ils ne conviennent pas au chargement différé et asynchrone. Ces scripts doivent être chargés en même temps que la page HTML, dans un ordre précis. Cela crée un gros problème car les navigateurs ne peuvent pas les charger ultérieurement, ce qui ralentit l’apparence générale du site Web. Vous pouvez envisager à l’avenir de migrer votre site vers le HTML et de l’héberger sur JamStack, mais vous ne pouvez pas utiliser le HTML généré qui dépend de jQuery et des événements DOM pour les déclencheurs.

Un autre inconvénient de jQuery est que les éléments sont rendus à partir du serveur, il n’y a pas de DOM virtuel et cela ajoute également du HTML inutile sur la page qui reste caché pour l’utilisateur.

Conclusion

Avec WP 5.8 et FSE au coin de la rue le mois prochain. Il est peut-être temps de revoir Gutenberg. Pendant de nombreuses années, les développeurs WordPress sont restés frustrés par l’absence d’un constructeur de pages dans le noyau de WordPress. Nous ferons une revue détaillée sur Gutenberg dans un autre post. Merci.