Catégories
Astuces et Design

WordPress et Jamstack | Astuces CSS

J'ai récemment animé un panel à la Jamstack Conf virtuelle de Netlify qui comprenait le PDG de Netlify Matt Biilman et le fondateur d'Automattic Matt Mullenweg. Le tout a été construit – du moins pour certains – comme une confrontation «Jamstack contre WordPress».

J'ai beaucoup de réflexions personnelles à ce sujet et je pense que je suis plus utile en tant qu'expert qu'en tant que modérateur. C'est l'une de mes conversations préférées en matière de technologie en ce moment! Alors permettez-moi de Blog.

Divulgation: Automattic et Netlify sont des sponsors actifs de ce site. J'ai des sites de production qui utilisent les deux, et honnêtement, je suis fan des deux, ce que je vais essayer de faire valoir. Il se trouve également que j'écris et publie ceci sur un site WordPress.

Histoire

  1. Richard MacManus a publié "Le co-fondateur de WordPress Matt Mullenweg n'est pas un fan de JAMstack" avec des citations d'une conversation par e-mail entre eux une ligne de Matt disant: "JAMstack est une régression pour la grande majorité des gens qui l'adoptent."
  2. Matt Biilmann a publié une réponse «Sur Mullenweg et le Jamstack – Régression ou avenir?» avec une section entière intitulée «La fin de l'ère WordPress».
  3. Les gens ont sonné en cours de route. Ohad Eder-Pressman, membre du conseil d'administration de Netlify, a écrit une lettre ouverte. Sarah Gooding a rassemblé une partie de l'activité sur WP Tavern (qui appartient à Matt Mullenweg). J'ai aussi répondu.
  4. Matt Mullenweg a clarifié ses remarques avec de nouveaux zingers.

Le débat a eu lieu le 6 octobree à Jamstack Conf Virtual 2020. Il n'y a pas de vidéo publique (désolé).

La pile

Comparer Jamstack à WordPress est un peu bizarre. Quoi est comparable est le fait que ce sont les deux routes que vous pourriez emprunter lors de la création d'un site Web. Une grande partie de cet article gardera cela à l'esprit et comparera les deux de cette façon. Pourquoi ils ne sont pas directement comparable parce que:

  • Jamstack est un descripteur vague d'une philosophie architecturale qui encourage les fichiers statiques sur les CDN et les services accessibles par JavaScript pour tous les besoins dynamiques.
  • WordPress est un CMS sur la pile LAMP.

Ces choses ne sont pas des pommes aux pommes.

Si nous nous en tenons à la empiler pendant un instant, la comparaison serait entre:

  • Hébergement statique + services
  • LAMPE

Un exemple de Static + Services est l'utilisation de Netlify pour l'hébergement (qui est statique) et l'utilisation de services pour faire tout ce que vous devez faire de dynamique. Peut-être que vous utilisez les propres formulaires et fonctionnalités d'authentification de Netlify et Hasura pour le stockage des données.

Sur une pile LAMP, vous disposez de MySQL pour stocker des données, vous n’avez donc pas recours à un service extérieur. Vous disposez également de PHP. Donc, avec ceux-ci (en plus des logiciels open-source), vous avez ce dont vous avez besoin pour l'authentification. Cela ne veut pas dire que vous jamais atteindre les services; vous le faites moins souvent car vous avez plus de technologie à portée de main à partir du serveur que vous avez déjà.

Jamstack: Hébergement statique en tant que hub, atteignant les services pour tout le reste.

LAMPE: Serveur qui fait beaucoup de travail en tant que concentrateur, atteignant quelques services si nécessaire.

Matt B. a qualifié la pile LAMP de «monolithe». Matt M. s'est opposé à ce terme et l'a appelé une «approche intégrée». Je ne suis pas informaticien, mais je pouvais voir les choses se passer dans les deux sens. Voici Wikipedia:

(…) une application monolithique décrit une application logicielle à un seul niveau dans laquelle l'interface utilisateur et le code d'accès aux données sont combinés en un seul programme.

Défini de cette façon, oui, WordPress semble être un monolithe, et pourtant l'article de Wikipedia continue:

(…) Une application monolithique décrit une application logicielle conçue sans modularité.

Vu de cette façon, semble disqualifier WordPress en tant que monolithe. L'architecture du hook et du plugin de WordPress est modulaire. 🤷‍♂️

Il serait intéressant d'entendre ces deux gars creuser la nuance là-bas, mais le logiciel est ce qu'il est. Un site WordPress auto-hébergé fonctionne sur un serveur avec une pile complète de technologies à sa disposition. Il est logique de demander autant que possible à ce serveur (c'est-à-dire intégré). Dans une approche Jamstack, le serveur est extrait de vous. Tout ce que vous devez faire est divisé en différents services (c'est-à-dire non intégrés).

L'approche WordPress, ne fait pas signifie que vous jamais atteindre des services extérieurs. Dans les deux piles, vous utiliserez probablement quelque chose comme Stripe pour les API de commerce électronique. Vous pourriez opter pour quelque chose comme Cloudinary pour un stockage et un service multimédia robustes. Même le service Jetpack de WordPress (que j'utilise et que j'aime) apporte beaucoup de puissance à un site WordPress auto-hébergé en se comportant comme un service tiers et déplacer des éléments tels que l'hébergement d'actifs et la technologie de recherche de vos propres serveurs en les transférant vers des serveurs cloud. Les deux piles sont des conglomérats de technologies.

Aucune pile n'est plus «château de cartes» ou plus enclin que l'autre. Tous les sites Web peuvent avoir cette métaphore «aussi forte que son lien le plus faible» s’applique à eux. Si un plugin WordPress expédie une version bloquée ou est corrompu lors du téléchargement, il peut gâcher mon site jusqu'à ce que je le répare. Si mes clés API deviennent invalides pour ma base de données sans serveur, mon site Jamstack peut être arrosé jusqu'à ce que je le répare. Si Stripe est en panne, je ne vends aucun produit sur aucun type de site jusqu'à ce qu'ils soient de nouveau en service.

Un point-virgule manquant peut couler n'importe quel site.

Tarification

WordPress.com a un plan gratuit, et c'est absolument un endroit où vous pouvez créer un site. (J'en ai plusieurs.) Mais vous n'y avez pas vraiment accès de style développeur tant que vous n'êtes pas sur le plan d'affaires à 25 $ par mois. WordPress auto-hébergé lui-même est open-source et gratuit, mais vous n'allez pas trouver un endroit pour créer un site WordPress auto-hébergé gratuitement. Il démarre bon marché et évolue. Vous avez besoin d'un hébergement LAMP pour exécuter WordPress. Voici un aperçu des plans d'hébergement assez bon marché:

Il y a de l'argent en jeu dès le départ.

Commencer gratuitement est beaucoup plus courant avec Jamstack, alors vous engagez des frais à différents moments. Jamstack étant plus récent, cela ressemble à un marché qui continue de se comprendre.

  • Vercel est gratuit jusqu'à ce que vous ayez besoin de membres de l'équipe ou de fonctionnalités telles que des sites protégés par mot de passe. Un seul site protégé par mot de passe coûte 150 $ / mois. Vous pouvez lancer l'authentification de base sur n'importe quel serveur avec Apache sans frais supplémentaires.
  • Netlify est très similaire, débloquant des fonctionnalités sur des plans plus élevés et offrant des fonctionnalités à la carte par site, telles que l'analyse (9 $ / mois) et l'authentification (5000 utilisateurs actifs coûtent 99 $ / mois).
  • AWS Amplify démarre gratuitement, mais comme tout sur AWS, votre utilisation est mesurée à de nombreux niveaux, comme les minutes de construction, le stockage et la bande passante. Ils ont un exemple de calcul d'une application Web qui compte 10000 utilisateurs actifs par jour et est mise à jour deux fois par mois, ce qui coûte 65,98 $ / mois.
  • Azure Static Web Apps n'a pas encore publié de prix, mais aura presque certainement un niveau gratuit ou une utilisation gratuite ou une autre.

Tout cela est un bon rappel que Netlify n'est pas le seul du jeu Jamstack. Jamstack signifie simplement hébergement statique plus prestations de service.

Vous ne pouvez pas faire de déclarations générales comme Jamstack est moins cher. Cela dépend beaucoup trop de l’utilisation et des besoins du site. Avec une utilisation élevée et un tas de services premium, Jamstack (un peu comme Serverless en général) peut devenir très coûteux. Jamstack affirme que leur prix d'entreprise commence à 3 000 $ / mois, et même si vous obtenez des éléments tels que l'authentification, les formulaires et la gestion des médias, vous n'obtenez pas de CMS ou de stockage de données, ce qui est susceptible de vous faire monter beaucoup plus haut.

Bien que ce site WordPress ne soit pas une entreprise, je peux vous dire qu'il nécessite un serveur de l'ordre de 1000 $ / mois, et cela suppose que Cloudflare est en face de lui pour aider à réduire la bande passante directement à l'hôte et à Jetpack gérant des choses comme l'hébergement multimédia et fonctionnalité de recherche. Mailchimp envoie notre newsletter. Wufoo alimente nos formes. Nous avons également des plugins payants, comme Advanced Custom Fields Pro et quelques modules complémentaires WooCommerce. Ce n’est pas tout. C’est probablement quelques milliers par mois, tout compte fait. Ce n'est pas unique à une approche intégrée, mais cela permet d'illustrer que le coût d'un site WordPress peut également être assez élevé. Ils ne publient pas de prix (une tactique d'entreprise courante), mais le service d'hébergement VIP WordPress d'Automattic commence sûrement à mi-4 chiffres avant de commencer à ajouter des éléments tiers.

Conclusion: il n'y a pas de changement radical de prix ici.

Performance

80% des performances Web sont une préoccupation frontale.

C’est une histoire vraie, mais elle repose également sur la base du serveur (en tenant compte du premier 20%). Le serveur frontal le plus rapide au monde ne semble pas du tout rapide si la première demande de retour du serveur prend plusieurs secondes. Vous devez vous assurer que la première demande est fumée rapidement si vous voulez un site rapide.

Le premier rectangle est la première réponse du serveur et le second est l'ensemble du front-end. Même avec un frontal rapide, il ne peut pas vous éviter un back-end lent.

Vous savez ce qui est super rapide? CDN globaux servant des fichiers statiques. C’est ce que vous voulez faire sur n’importe quel site Web, quelle que soit la pile. Bien que ce soit la base de Jamstack (hébergement statique soutenu par CDN), cela ne signifie pas que WordPress ne peut pas le faire.

Vous prenez un index.html fichier avec du contenu statique, mettez-le sur Netlify, et ça va fumer vite. Peut-être que votre générateur de site statique crée ce fichier (qui, il convient de le souligner, pourrait très bien obtenir du contenu de WordPress). Il y a quelque chose de très agréable dans la robustesse et la base solide de cela.

Par défaut, WordPress ne crée pas de fichiers statiques capturables sur un CDN global. WordPress répond aux requêtes d'une seule origine, exécute PHP, qui demande des informations à la base de données, avant qu'une réponse ne soit assemblée, puis, enfin, la page est renvoyée. Cela peut être assez rapide, mais il est beaucoup moins robuste qu’un fichier statique sur un CDN global et il est beaucoup plus facile de submerger de demandes.

Les hébergeurs WordPress le savent et essaient de résoudre le problème au niveau de l'hébergement. Regardez simplement l'approche de WP Engine. Sans que vous fassiez quoi que ce soit, ils utilisent un cache de page afin que le site puisse essentiellement renvoyer un actif statique plutôt que de devoir exécuter PHP ou accéder à une base de données. Ils utilisent également toutes sortes d'autres mises en cache, y compris un partenariat avec Cloudflare pour faire la meilleure mise en cache possible. Au moment où j'écris ceci, mon site shoptalkshow.com est littéralement tombé en panne. J'ai écrit à l'hôte, Flywheel, pour voir ce qui se passait. Il s'avère que lorsque je suis allé là-bas pour activer un site de préparation, j'ai basculé un mauvais commutateur et désactivé leur mise en cache. Le site n'a pas pu gérer le trafic et vient de mourir. Le fait de réactiver le commutateur de mise en cache l'a résolu instantanément. Je n'avais pas Cloudflare devant le site, mais j'aurais dû.

Cloudflare fait partie de la sauce magique pour rendre WordPress rapide. Le simple fait de le mettre devant votre site WordPress auto-hébergé va faire beaucoup de travail pour le rendre rapide et fiable. L'une des pièces manquantes a été la grande mise en cache du HTML lui-même, dont ils ont littéralement traité ce mois-ci et qui peuvent maintenant être également mises en cache. Il y a une sorte d'ironie amusante dans le fait que la mise en cache de WordPress signifie la mise en cache des demandes en tant que HTML statiques et actifs statiques, et leur service à partir d'un CDN global, ce qui est essentiellement ce que Jamstack est en fin de compte.

Matt M. a mentionné que WordPress.com utilise des CDN mondiaux qui se déclenchent à certains niveaux de trafic. Je ne sais pas si c'est Cloudflare ou non, mais je n'en doute pas.

Avec Cloudflare devant un site WordPress, Je vois les mêmes numéros de première réponse que sur les sites Netlify sans Cloudflare (car il est déconseillé d'utiliser Cloudflare devant les sites hébergés par Netlify). Ce sont des nombres de millisecondes à 2 chiffres, ce qui est très, très bien.

Première demande sur le site WordPress css-tricks.com, hébergé par Flywheel avec Cloudflare en face. Très vite.
Première demande sur mon site Jamstack, conférences.css-tricks.com, hébergé par Netlify. Très vite.

À partir de cette base, toute discussion sur les performances devient spécifique au front-end. Les tactiques frontales pour la vitesse sont les mêmes quel que soit le serveur, l'hébergement ou la situation du CMS sur le back-end.

Sécurité

Il y a beaucoup plus d'histoires sur les sites WordPress piratés que les sites Jamstack. Mais est-il juste de dire que WordPress est moins sécurisé? WordPress continue sur une vingtaine d'années d'histoire et a quelques ordres de grandeur de plus de sites construits dessus que Jamstack. Mis à part la sécurité, vous obtiendrez plus d'histoires de WordPress avec ces chiffres.

Matt M a mentionné que whitehouse.gov était sur WordPress, qui est évidemment un site qui a besoin des plus hauts niveaux de sécurité. Ce n’est pas que WordPress lui-même est un logiciel non sécurisé. C’est ce que vous en faites. Avez-vous des mots de passe non sécurisés? Ce n’est pas sûr, quelle que soit la plate-forme que vous utilisez. Le serveur lui-même n'est-il pas sécurisé via les autorisations de fichiers ou les niveaux d'accès? Ce n’est pas exactement la faute du logiciel, mais vous êtes peut-être dans cette position parce que du logiciel. Utilisez-vous la dernière version de WordPress? L’utilisation est fragmentée, au mieux, et plus la version est ancienne, moins elle sera sécurisée. Rusé.

Il peut être plus intéressant de penser à la sécurité vecteurs. Autrement dit, à quels moments il est possible se faire pirater. Si vous avez un fichier statique sur un hébergement statique, je pense qu'il est prudent de dire qu'il existe assez peu de vecteurs d'attaque. Mais encore, il y en a:

  • Votre compte d'hébergement pourrait être piraté
  • Votre dépôt Git pourrait être piraté
  • Votre compte Cloudflare pourrait être piraté
  • Votre nom de domaine pourrait être volé (cela arrive)

C'est également vrai pour un site WordPress, mais il existe des vecteurs d'attaque supplémentaires tels que:

  • Code côté serveur: XSS, mauvais plugins, exécution à distance, etc.
  • Vulnérabilités de la base de données
  • Exécuter une version plus ancienne et obsolète de WordPress
  • Le système de connexion est directement sur le site lui-même, par ex. les méchants peuvent marteler /wp-login.php

Je pense qu'il est juste de dire qu'il y a plus de vecteurs d'attaque sur un site WordPress, mais il y a beaucoup de vecteurs sur n'importe quel site. Le compte d'hébergement de n'importe quel site est un grand vecteur. Tout ce qui se trouve dans la chaîne DNS. Tous les services tiers avec des connexions. Tout ce qui a une clé API.

Expérience personnelle: ce site est sur WordPress et n'a jamais été piraté, mais pas faute d'essayer. Je sens que je dois penser plus à la sécurité sur mes sites WordPress qu'à mes sites qui sont seulement construit à partir de générateurs de sites statiques.

Mise à l'échelle

La mise à l'échelle de l'une ou l'autre approche coûte de l'argent. Ce site WordPress n'est pas massivement mis à l'échelle, mais nécessite une mise à l'échelle décente par rapport aux exigences du serveur d'entrée de gamme. Je sers tout le trafic via Cloudflare, donc un pic au cours des 30 derniers jours me dit que je sers 5 To de bande passante par mois.

Sur un plan Netlify Business (600 Go de trafic pour 99 $, puis 20 $ pour 100 Go supplémentaires), ce calcul revient à 979 $. Rappelez-vous quand j'ai dit que ce site nécessite un serveur qui coûte environ 1000 $ / mois? J'ai écrit cela avant de lancer ces chiffres, donc j'étais très proche (allez-moi). Jamstack contre WordPress à l'échelle de ce site est plutôt au coude à coude. Tous les hôtes vont facturer la bande passante et ont des plafonds avec des frais supplémentaires. Amplify facture 0,15 USD / Go sur une limite mensuelle de 15 Go. Les frais de Flywheel (mon hébergeur WordPress) sont basés sur un plafond mensuel de visiteurs et, au-delà, c'est 1 $ pour 1000.

L'histoire de la mise à l'échelle de WordPress est:

  • Utilisez un hôte capable de le gérer et disposant de sa propre stratégie de mise en cache éprouvée.
  • CDN tout (ce qui signifie généralement mettre Cloudflare devant lui).
  • En fin de compte, vous allez payer pour cela.

L'histoire de la mise à l'échelle Jamstack est la suivante:

  • L'hôte et les services sont conçus pour évoluer.
  • Vous devez penser à la mise à l'échelle Moins en terme de ce service peut-il gérer cela ou dois-je déménager?
  • Vous devez penser à la mise à l'échelle plus en ce qui concerne le fait que chaque aspect de chaque service aura des prix dont vous devez garder un œil.
  • En fin de compte, vous allez payer pour cela.

J'ai dû me déplacer un peu avec mon hébergement WordPress, trouver des hébergeurs qui correspondent aux besoins actuels du site. Déplacer un site WordPress n’est pas simple, mais c’est beaucoup plus facile que de passer à un autre CMS. Par exemple, si vous créez un site Jamstack sur un CMS headless qui devient trop cher, le coût du déplacement est un travail plus important que le changement d'hôtes.

J'aime ce que Dave Rupert a écrit l'autre jour (dans une conversation Slack) sur la comparaison des performances entre les deux:

Jamstack: utilisez n'importe quel élément pour créer votre truc, il y a des addons pour vous aider et utiliser Notre truc pour le déployer sur un CDN afin qu'il ne tombe pas.

WordPress: utilisation Notre truc pour créer votre truc, il existe des modules complémentaires pour vous aider, et vous devez utiliser certains hôtes pour qu'il ne tombe pas.

Il existe également d'autres types de «mise à l'échelle». Je pense à quelque chose comme nombre d'utilisateurs. C'est quelque chose que toutes sortes de services utilisent pour les niveaux de tarification, ce qui est une mesure compréhensible. Mais c'est gratuit dans WordPress. Vous pouvez avoir autant d'utilisateurs avec autant d'autorisations nuancées que vous le souhaitez. Ce n’est que le CMS. L’ajout d’autres services peut donc vous facturer à la tête. Vercel ou Netlify vous facturent par le responsable des comptes d'équipe. Contentful (un CMS headless populaire) commence à 489 $ / mois pour les équipes. Même le niveau Équipe de GitHub est de 4 USD par utilisateur si vous avez besoin de quelque chose que le compte gratuit ne peut pas faire.

Diviser l'avant et l'arrière

C'est l'une des grandes choses qui enthousiasme les gens à l'idée de créer avec Jamstack. Si toutes les fonctionnalités et le contenu de mon site sont derrière des API, cela libère le front-end pour construire comme il le souhaite.

  • Voulez-vous créer un site entièrement statique? OK, appuyez sur cette API pendant le processus de construction et faites-le.
  • Voulez-vous créer un site rendu client avec React ou Vue ou autre? Très bien, appuyez sur le côté client de l'API.
  • Voulez-vous diviser le milieu, pré-rendu certains, rendu client certains, et serveur-rendu certains? Cool, c'est une API, vous pouvez y accéder comme vous le souhaitez.

Cette flexibilité est parfaite pour les constructions sur champs verts, mais les gens sont tout aussi enthousiastes flexibilité future théorique. Si toutes les fonctionnalités et tous les contenus sont basés sur l'API, vous avez entièrement divisé l'avant et l'arrière, ce qui signifie que vous pouvez changer l'un ou l'autre à l'avenir avec plus de flexibilité.

  • Tant que vos API continuent de cracher ce que le front-end attend, vous pouvez réorganiser le back-end sans perturber le front-end.
  • Tant que vous obtenez les données dont vous avez besoin, vous pouvez réorganiser le front-end sans perturber le back-end.

Ce type de division semble «sûr pour l'avenir» pour les sites d'une certaine taille et d'une certaine échelle. Je ne peux pas vraiment mettre le doigt sur ce que sont ces chiffres d'échelle, mais ils sont là.

Si vous avez déjà procédé à une réarchitecture majeure de site juste pour s'adapter à un côté ou à l'autre, passer à un système où vous avez divisé le back-end et le front semble certainement être une décision intelligente.

Une fois que nous nous sommes séparés, tant que les attentes sont maintenues, l'arrière (B) et l'avant (F) sont libres d'évoluer indépendamment.

Tu pouvez diviser un site WordPress (nous y reviendrons dans la section «Utiliser les deux»), mais par défaut, WordPress est une approche très intégrée où le front-end est construit à partir de thèmes en PHP en utilisant des API très spécifiques à WordPress. Pas du tout divisé.

Expérience développeur

Jamstack a fait du bon travail en priorisant fortement l'expérience des développeurs (DX). J'ai entendu quelqu'un l'appeler «un optimum local», ce qui signifie que Jamstack est conçu autour d'une expérience de développement local (et de développeur local).

  • Vous devez travailler localement. Vous travaillez dans votre propre environnement de développement confortable (local, rapide, personnalisé).
  • Git est un citoyen de premier ordre. Vous poussez vers votre branche de production (par ex. master ou main), votre processus de génération s'exécute et votre site est déployé. Vous obtenez même une URL de prévisualisation de ce que sera le site de production pour chaque pull request, ce qui est une fonctionnalité incroyablement intéressante.
  • Utilisez l'outillage de votre choix. Vous voulez pré-construire un site dans Hugo? Fonce. Tu as appris create-react-app à l'école? Utiliser ça. Vous voulez expérimenter le nouveau framework de jour cool? Ayez à lui. Il y a beaucoup de liberté pour créer comme vous le souhaitez, en tirant parti du fait que vous pouvez exécuter une compilation et déployer le dossier de votre dépôt que vous souhaitez.
  • Ce que vous ne pas avoir à faire est également important. Vous n’avez pas à gérer HTTPS, vous n’avez pas à vous soucier de la mise en cache, vous n’avez pas à vous soucier des autorisations de fichiers, vous n’avez pas à configurer de CDN. Même les développeurs avancés apprécient de devoir faire moins.

Ce n'est pas que WordPress ne considère pas l'expérience des développeurs (par exemple, ils ont une CLI et il peut faire des choses utiles, comme des blocs d'échafaudage), mais le DX ne me semble pas au cœur du projet.

  • Exécuter WordPress localement est délicat, vous obligeant à exécuter une pile (X) AMP d'une manière ou d'une autre, ce qui implique un logiciel tiers notoirement délicat. Dieu merci pour Local by Flywheel. Il y a des conseils mais cela ne semble pas être une priorité.
  • Qu'est-ce qui devrait aller dans Git? À ce jour, je ne sais pas vraiment, mais je me suis largement arrêté sur l'ensemble /wp-content dossier. Cela me semble étrange qu'il n'y ait pas de conseils ou de meilleures pratiques évidentes.
  • Vous êtes totalement seul pour le déploiement. Même les hébergeurs spécifiques à WordPress ne le clouent pas vraiment ici. C'est en grande partie juste: voici vos identifiants SFTP.
  • Même si vous avez mis en place un bon pipeline de développement et de déploiement local (je suis satisfait du mien), cela ne vous aide pas vraiment à déplacer la base de données, vous êtes donc seul là-bas également.

Ce sont toutes des choses qui peuvent être résolues, et la communauté WordPress est si grande que vous y trouverez beaucoup d’informations, mais je pense qu’il est juste de dire que WordPress n’a pas de DX au cœur. C'est un peu far west-y même après toutes ces années.

En fait, j’ai constaté que, parce que l’encouragement d’un environnement de développement local sain est tellement mis de côté, beaucoup de gens n’en ont pas du tout. C’est anecdotique, mais maintenant deux fois plus d’années je me suis retrouvé impliqué dans les sites d’autres personnes qui fonctionnent entièrement production uniquement. Ce serait une chose s'il s'agissait de sites très simples avec un comportement largement par défaut, mais ceux-ci ont été tout sauf. Ils sont très compliqués (bien plus que ce site) impliquant des connexions d'utilisateurs publics, des adhésions et des autorisations payantes, des constructeurs de pages, des codes courts personnalisés, du CSS personnalisé et juste un sacré nombre de pièces mobiles. Cela m'a fait peur à mort. Je ne voulais rien toucher. Ils éditaient du PHP en direct pour faire fonctionner les choses – codage cowboy, comme les gens appellent ça en plaisantant. Une erreur de syntaxe et le site est arrosé, peut-être même la page que vous regardez.

Le fait que WordPress alimente une si grande partie du Web sans DX particulièrement bon est très intéressant. Il n'y a pas de Jamstack sans DX. C'est une chose entièrement axée sur les développeurs. Avec WordPress, il n'y a probablement pas du tout de développeur sur la plupart des sites. Il est installé (ou vient d'être activé, dans le cas de WordPress.com) et le propriétaire du site le prend à partir de là. Le propriétaire du site est comme un développeur en ce sens qu'il a beaucoup de puissance, mais n'écrit peut-être pas du tout de code.

À cette fin, je dirais que WordPress se concentre beaucoup plus sur l'UX que sur le DX, ce qui est une grande partie de tout cela …

CMS et UX de l'utilisateur final

WordPress est un très bon CMS. Même si tu Je n'aime pas ça, il y a beaucoup de gens qui aiment ça, et les chiffres parlent d'eux-mêmes. Ce que vous obtenez, lorsque vous décidez de créer un site avec WordPress, est une aide considérable de capacité à créer à peu près n'importe quel type de site que vous souhaitez. Il est peu probable que vous ayez cela Oups, je me suis peint dans un coin ici situation avec WordPress.

C’est un gros problème. Jenn a mis le doigt dessus, notant que les personnes qui utilisent WordPress représentent une histoire plus importante que les besoins d'un développeur.

WordPress peut faire une tonne absolue de choses:

  • Blog (ou être tout type de site de type CMS orienté contenu)…
    • Avec des aperçus de contenu, ce qui est possible mais délicat sur Jamstack
  • Traiter les utilisateurs / autorisations…
  • commerce électronique
  • Formulaires de processus
  • Gérez les plugins vers la lune et inversement

Jamstack peut absolument faire toutes ces choses aussi, mais maintenant c'est Jamstack qui se trouve sur le territoire du Far West. Lorsque vous regardez des didacticiels sur la façon de stocker des données, ils impliquent souvent d'expliquer comment écrire des CRUD fonctions pour une base de données cloud. Cela tient au métal qui peut être très puissant, mais c'est loin de cliquer sur quelques boutons, ce que WordPress ressent la plupart du temps.

Je parie que je pourrais probablement bricoler une configuration de base de commerce électronique Jamstack avec des API Stripe, ce qui est très cool. Mais ensuite, je devenais nerveux quand j'ai besoin de commencer à penser à la gestion des stocks, aux zones d'expédition, aux variations de produits et qui sait quoi d'autre qui se complique dans le commerce électronique, me faisant souhaiter que j'avais quelque chose de super robuste qui a tout fait pour moi .

Parfois, nous, les développeurs, construisons des sites rien que pour nous (je fais plus que ma juste part de cela), mais je dirais que les développeurs construisent principalement des sites pour d'autres personnes. La question la plus importante est donc: est-ce que je construis quelque chose qui donne du pouvoir aux personnes pour lesquelles je le construis?

Vous pouvez tirer une bonne expérience de gestionnaire de site quoi qu'il arrive, mais WordPress a sûrement prouvé qu'il livrait dans ce département sans trop demander beaucoup en termes de développement personnalisé.

Jamstack a cependant quelques astuces que j'aurais aimé réussir sur WordPress. En voici un gros pour moi: le contenu soumis par les utilisateurs et les mises à jour. J'ai littéralement trois sites Web qui en bénéficient maintenant. Un site sur les conférences, un site sur le sans serveur et un site à venir sur le codage des polices. WordPress aurait pu absolument faire un excellent travail sur ces trois sites. Mais ce que je veux vraiment, c'est que les gens puissent mettre à jour et soumettre du contenu de manière à ce que je puisse être comme: Oui, ça a l'air bien, fusionnez. En adoptant une approche Jamstack, le contenu est dans des dépôts GitHub publics et tout le monde peut y participer.

Je pense que c’est super génial. Cela ne nécessite même pas nécessairement que quelqu'un du public sache ou comprenne Git ou GitHub, car Netlify CMS a ce concept de création ouverte, qui conserve toute l'expérience de contribution dans le navigateur avec l'interface utilisateur pour l'édition.

Utiliser les deux

C'est un gros problème que je vois souvent évoqué. Même Netlify eux-mêmes disent: «Il n'y a pas de Versus».

Voici l'affaire:

  • Le «A» dans «Jam» signifie API. Utilisez les API pour créer votre site au moment de la création ou côté client.
  • Les sites WordPress, par défaut, ont une API REST (et peuvent également avoir une API GraphQL).
  • Alors, cliquez sur cette API pour les données CMS sur votre site Jamstack.

Ouais, totalement. Cela fonctionne et les gens le font. Je trouve que c'est plutôt cool.

Mais…

  • Exécuter un site WordPress quelque part en plus de votre site Jamstack signifie … que vous exécutez un site WordPress en plus de votre site Jamstack. Il y a là un coût et une dette technique.
  • Vous n’obtenez souvent pas toute la valeur de WordPress. Accéder à une API pour les données pourrait être tout ce dont vous avez besoin, mais c'est un super, très différent approche de la construction d'un site plutôt que de la construction d'un thème WordPress. Vous n'obtenez aucune des autres valeurs de WordPress. Je pense à des situations comme celle-ci: vous trouvez un plugin soigné qui ajoute un bloc Gutenberg sophistiqué à votre site. Cela "fonctionnera simplement" sur un site WordPress, mais il a probablement un comportement frontal spécial qui ne fonctionnera pas si tout ce que vous faites est d'aspirer le HTML d'une API. Il met probablement en file d'attente certains scripts et styles supplémentaires que vous utiliserez vous-même pour déterminer comment incorporer où votre front-end est hébergé, et vous-même pour maintenir les mises à jour.

Voici quelques joueurs qui ont tous une approche unique pour «utiliser les deux»:

  • Frontity: un framework React pour WordPress. Il semble que vous puissiez l'exécuter avec un serveur Node afin que les pages soient rendues côté serveur ou en tant que générateur de site statique. Quoi qu'il en soit, WordPress est le CMS, mais vous créez le front-end avec React et obtenez des données de l'API REST.
  • WP2Static: Un plugin WordPress qui construit une version statique de votre site et peut le déployer automatiquement lorsque des modifications sont apportées.
  • Strattic: Ils hébergent le site WordPress dynamique pour vous (qu'ils appellent «mise en scène») et vous travaillez normalement avec WordPress là-bas. Ensuite, vous choisissez de déployer, et ils hébergent également une version statique de votre site pour vous.

Il existe de nombreuses autres façons d'intégrer les deux. Voici nos propres Geoff et Sarah qui parlent d'utiliser ensemble WordPress et Jamstack en utilisant Vue / Nuxt avec l'API REST et l'hébergement sur Netlify.

N'utiliser ni l'un ni l'autre

Au cas où cela ne serait pas clair, il existe de nombreuses façons de créer des sites Web. Si vous créez un site Ruby on Rails, ce n’est pas Jamstack ou WordPress. Vous pourriez dire que cela ressemble plus à un site WordPress en ce sens qu'il nécessite un serveur et que vous utiliserez ce serveur pour en faire autant que vous le pouvez. Vous pourriez également affirmer que cela ressemble plus à Jamstack en ce que, même s'il ne s'agit pas d'un hébergement statique, il encourage l'utilisation d'API et la mise en place de services.

Le Web est un grand endroit, un gang, et ce n’est pas un jeu à somme nulle. Je m'attends à ce que WordPress continue de croître et Jamstack pour continuer à se développer car le web lui-même se développe. Même si nous ne considérons que le pourcentage de part de marché, je encore parie que les deux vont grandir, poussant tout le reste en tranches plus petites.

Choisir

Je ne vais même pas y aller. Non pas parce que j’évite de jouer aux favoris, mais parce que ce n’est pas nécessaire. Je ne vois pas de développeurs se ronger les ongles en essayant de choisir entre une approche WordPress ou Jamstack pour créer un site Web. Nous sommes au point où les technologies sont suffisamment bien comprises pour que le processus se déroule comme suit:

  1. Mettre un pantalon adulte
  2. Évaluer les besoins et les résultats
  3. Choisissez des technologies

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *