DE{CODE} : Quand choisir Headless pour les clients

Lorsqu'un client a des exigences de performance et de sécurité, quand une agence devrait-elle choisir WordPress traditionnel ou WordPress sans tête pour le travail ? Découvrez-en plus dans cette session DE{CODE}, avec un panel d'experts d'agences qui pèsent sur les avantages, les contraintes, les opportunités et les compromis de l'absence de tête.

Diapositives de la session

Transcription du texte intégral

HASHIM WARREN : Bonjour, bienvenue dans notre panel, Quand choisir Headless WordPress pour les clients. Je m'appelle donc Hashim Warren et je suis le Product Marketing Manager d'Atlas, notre solution pour Headless WordPress. Et l'une des premières questions que j'ai reçues des gens lorsqu'ils adoptent ou veulent adopter Headless WordPress, c'est quand dois-je utiliser WordPress traditionnel, tout en un WordPress, et quand dois-je utiliser Headless WordPress.

Donc, si j'ai un client qui a des exigences de performance et de sécurité, comme quoi dois-je penser en termes d'adoption, ou de choix de WordPress Headless ou traditionnel. Et aussi, si je choisis Headless WordPress, à quoi dois-je m'attendre, dans quoi je m'embarque ici. Nous avons donc aujourd'hui un excellent panel avec une expérience à la fois des projets WordPress traditionnels et des projets WordPress sans tête qui sera en mesure de répondre à certaines des grandes questions que je sais que beaucoup d'entre vous se posent.

Donc, aujourd'hui avec moi, nous avons Jonathan Jeter, qui est le directeur de la production technique chez Click Here Labs. Nous avons également Stephen Brooks, le directeur de la technologie chez Springbox. Nous avons également James Squires, le directeur de la technologie de l'espace 150. Et nous avons également Tayo Onabule, le directeur général de drawl.

Donc, je veux juste faire venir le panel maintenant, afin que nous puissions commencer cette conversation. Alors commençons la conversation de cette façon. Dites-moi simplement ce qui vous a personnellement, ou votre agence, intéressé par Headless WordPress en premier lieu. Et Jonathan, pouvez-vous commencer ?

JONATHAN JETER : Bien sûr. Nous sommes donc intéressés depuis un certain temps à travailler dans l'espace Headless. Et la principale raison pour laquelle nous nous y sommes intéressés était que nous voulions créer des projets plus vastes qui intégreraient des données provenant de plusieurs sources. Et l'API WordPress n'était pas encore là. Nous travaillions donc sur différentes manières de présenter la couche frontale, toujours en utilisant le contenu de WordPress. Et donc, c'est essentiellement ce que nous faisons depuis environ cinq à sept ans maintenant, essayant de comprendre quelle était la meilleure façon de le faire.

Et maintenant, c'est beaucoup plus facile qu'avant, évidemment il y a beaucoup plus - il y a un large éventail d'options quant à la façon dont vous allez le faire. Et donc, nous avons vu l'espace grandir, et nous sommes vraiment ravis de savoir où il va. Il

HASHIM WARREN : Génial. Et Stephen, avez-vous une histoire similaire? Qu'est-ce qui vous a intéressé, vous ou votre agence, à Headless WordPress ?

STEPHEN BROOKS : Oui, donc nous sommes dans l'espace Headless depuis environ 2015, traitant traditionnellement des plates-formes CMS basées sur la confiture. Au cours des dernières années, il a été difficile de traiter avec certaines équipes marketing travaillant à l'intérieur d'un système de bourrage, simplement à cause du changement de paradigme dans la saisie de contenu, par opposition à une approche de type publication et page.

Nous avons également essayé, tout comme Jonathan, de tirer parti de l'API WordPress. C'est un peu lourd, cela ne vous donne pas vraiment exactement ce dont vous avez besoin tout le temps. Chaque fois que WP Engine mentionnait Atlas et parlait des technologies sous-jacentes, c'était le baiser du chef avec ce que nous faisions traditionnellement dans l'espace de confiture.

C'est donc maintenant une conversation vraiment facile avec nos clients, car presque tous les spécialistes du marketing ont de l'expérience dans WordPress, mais les développeurs bénéficient en plus d'une solution Headless. Ainsi, vous bénéficiez d'une atténuation des risques de sécurité, ainsi que de quelques-unes des interactions haut de gamme avec une couche de présentation basée sur React. Cela a donc été notre véritable moteur ici récemment.

HASHIM WARREN : C'est génial. Tayo, pouvez-vous nous raconter votre histoire, et juste pour enchaîner avec cela, pouvez-vous nous dire comment convaincre les éditeurs d'adopter Headless WordPress ?

TAYO ONABULE : Ouais. Donc, je veux dire, je pense que, dans notre cas, nous avons eu une entrée légèrement plus récente et un peu différente dans l'espace Headless WordPress. L'un des principaux moteurs pour nous est l'un de nos clients Android Authority, qui a une portée assez large. En quelque sorte, à l'heure actuelle, on fait allusion au genre de 20 millions de visiteurs mensuels.

Et leurs besoins sont assez simples d'une certaine manière. Ils ont besoin d'un très bon référencement, comme le niveau supérieur. Et ils ont beaucoup de concurrents très compétents autour d'eux. Alors oui, un très bon référencement, de très bonnes performances et une très bonne expérience de lecture pour tous les articles qu'ils publient.

Donc, Headless était vraiment - cela est vraiment venu pour nous dans le cadre de la conversation alors que nous essayions de faire tout ce que nous pouvions pour trouver un moyen de faire en sorte que leurs sites WordPress existants répondent à tous ces besoins. Vraiment au maximum, en gros. Et Headless, d'abord, c'était juste pour moi de faire quelques recherches et de me dire, oh, eh bien, peut-être que nous pourrions, peut-être essayer.

Et nous sommes allés de plus en plus loin et nous avons traversé le processus de convaincre l'équipe. Mais au fur et à mesure que nous avancions dans son développement, nous avons commencé à réaliser que, oui, cela répondait à toutes ces questions principales, comme les performances SEO et une expérience, mais cela nous a également donné une flexibilité totale au fil des années. sur.

Nous avons lancé, je crois que c'était en mai de l'année dernière, donc nous arrivons à l'anniversaire de cela en fait. , Mais oui, depuis ce lancement, nous avons réussi à créer un grand nombre d'intégrations dans le site. Tout cela aurait été considérablement plus difficile si nous avions été sur WordPress monolithique ou tout en un. Cette flexibilité que cela vous donne est en quelque sorte l'une des - c'est l'une des choses que je disais à Android Authority que nous aurions, mais je ne pense pas avoir tout à fait réalisé l'ampleur et la liberté que cela offre, en gros.

HASHIM WARREN : C'est génial. Donc, jusqu'à présent, nous avons entendu parler de performances SEO, de flexibilité pour les développeurs, de flexibilité en termes de type de projet, ainsi que de la possibilité pour les éditeurs de s'en tenir à un CMS qu'ils connaissent. Jimmy, votre expérience correspond-elle à tout cela, ou avez-vous quelque chose à ajouter en termes de ce qui vous a attiré, vous ou votre agence, vers Headless WordPress ?

JAMES SQUIRES: Oui, je pense que beaucoup de ces choses que nous partageons aussi. La seule chose que j'ajouterais probablement que cela va peut-être paraître est un peu égoïste au début, mais j'y arriverai en quelque sorte et pourquoi c'est une bonne chose. Mais vraiment pour nous, c'était vraiment axé sur la satisfaction des développeurs.

Nous venons principalement d'un environnement de framework basé sur React et React, en quelque sorte entrant dans WordPress. Et nos clients demandaient de plus en plus WordPress, mais nos ingénieurs ne sont vraiment pas satisfaits de faire du développement basé sur des thèmes pour la plupart. Nous le faisons toujours lorsqu'il y a encore des applications où cela a beaucoup de sens, mais si vous êtes des développeurs satisfaits du produit et de ce qu'ils construisent, je trouve que le résultat est souvent une expérience stellaire pour qu'il y ait est un réel avantage pour nos clients, même si notre saut dans ce domaine était en quelque sorte centré sur quelque chose que nos ingénieurs voulaient faire.

HASHIM WARREN : C'est génial. L'une des choses que de nombreuses personnes qui regardent cela auront entendues lors des conférences, la différence entre le développement basé sur des thèmes pour WordPress et le développement basé sur des composants. Quelqu'un peut-il en parler? Les avantages d'adopter une approche basée sur les composants lors de la création de sites Web ?

TAYO ONABULE : Oui, j'aimerais vraiment me lancer là-dedans, en fait. Tout comme, je suis sûr que nous avons tous des exemples de cela, mais je pense que l'une des choses les plus satisfaisantes qui se produisent lorsque vous travaillez avec des bibliothèques JavaScript, comme celles de React, d'après notre expérience en tout cas, est oui, comme vous le dites, accès à ce type de style de construction basé sur les composants.

Et cela signifie que d'une part, vous pouvez diviser une conception de site entière en ces composants qui sont beaucoup plus flexibles. Disons donc, à titre d'exemple, que vous pourriez avoir un bloc sur une page qui a deux styles différents. Un, où l'image est sur le côté gauche et le texte est sur le côté droit, disons. Juste comme une sorte d'exemple simple. Et React, c'est un cas où vous avez un bloc avec un modificateur, essentiellement, pour dire simplement, inversez l'ordre du texte et de l'image.

Lorsque nous parlons de monolithique, vous êtes essentiellement juste, oui, peut-être que vous commencez sur la même base, mais vous devez très rapidement séparer les deux, et vous avez maintenant deux choses distinctes. Et les changements, dans une certaine mesure, doivent être répartis sur deux choses distinctes. Et c'est ce genre de concept qui signifie qu'au fur et à mesure que vous vous lancez dans des utilisations à plus grande échelle pour les frontaux Headless, cette flexibilité et cette cohérence que vous pouvez avoir sur l'ensemble d'un site, sur toutes les utilisations d'un composant particulier, signifient que le développement , comme James l'a dit plus tôt, est tellement plus satisfaisant pour les développeurs.

C'est une expérience considérablement plus agréable. Vous pouvez vraiment dire que React a été conçu pour en quelque sorte maximiser la sortie des développeurs, et c'est et c'est que, encore une fois, comme le dit James, tout cela est transmis au client. Parce que je pense que vous pouvez dire quand quelque chose a été fait avec amour et plaisir, cela se traduit toujours par un meilleur résultat.

STEPHEN BROOKS : Ouais, pas seulement ça, Tayo. Mais il y a aussi d'autres grands avantages à cela. Je veux dire que vous avez vraiment frappé à la tête pour la satisfaction des développeurs, mais si vous jetez un coup d'œil au développement traditionnel basé sur des modèles, par opposition à un développement basé sur des composants, des tests unitaires, c'est vrai. Il est vraiment difficile d'implémenter n'importe quel type de test unitaire à l'intérieur d'une approche thématique. Avec un composant, boom, il est là pour vous.

Mais je veux ajouter un point à cela, mais ce n'est pas nécessairement pour les développeurs, c'est plus pour les propriétaires d'entreprise. Généralement, avec une approche basée sur les composants, votre niveau d'effort diminue considérablement par rapport à une page de thème donnée, car vos composants, vous allez les réutiliser partout, n'est-ce pas. Et cela ne nécessite pas de temps de saisie supplémentaire, de frappe, pour aller ajouter ce bloc supplémentaire partout où il va. Vous venez de le construire une fois. Chaque fois que vous en consommez, vous hydratez votre build. Boum, vous avez terminé. C'est si beau, si rapide. C'est merveilleux.

JONATHAN JETER : Et nous avons dû former notre personnel créatif, c'est vrai, parce qu'ils sont tellement habitués à aimer, OK, ce site est composé de 5 modèles, ou celui-ci est n'importe quoi. Nous sommes comme, non, ne t'éloigne pas de ça, d'accord. Et donc nous avons fini par l'appeler. Concevez simplement la page de l'évier de la cuisine, à droite, une page avec tout ce qu'elle contient, à droite, et nous la construirons à partir de là. Alors oui, cela a rendu le développement beaucoup plus facile, mais nous avons dû former le personnel à tous les niveaux pour nous assurer qu'ils comprennent ce que nous faisons et comment nous le construisons.

JAMES SQUIRES : Ouais, même dans les opérations. Je veux dire, cela a changé la façon dont nos propositions pour les clients sont façonnées lorsque nous faisons cela. Nous parlons de quantités de blocs et de la manière dont nous les construisons, par opposition aux modèles. Et c'est juste un tel changement de paradigme, je pense, pour certains, en particulier du côté du marketing, à penser - vous avez des pages interminables de différents types de blocs. Ce sont vraiment ces blocs et composants de base, et ce que nous construisons et délimitons.

TAYO ONABULE : Et juste un dernier élément à ce sujet. Et je pense que la mention des propositions est un très bon point, car le processus Headless modifie massivement toutes les estimations que vous pourriez avoir sur ce qu'une fonctionnalité va prendre ou une nouvelle mise en page va prendre. Le fait est qu'il diminue très régulièrement au fil du temps. Plus votre bibliothèque de composants est large, moins il en faut pour ajouter un style supplémentaire ou quelque chose, modifier un style sur l'ensemble du site, ajouter une nouvelle mise en page. Toutes ces choses deviennent de plus en plus faciles.

Et je pense que c'est gratifiant pour tout le monde, pour être honnête.

HASHIM WARREN : Donc, c'est vraiment intéressant. Ce n'est pas seulement Headless par rapport à un site tout-en-un, c'est un développement basé sur des modèles par rapport à un développement basé sur des composants. Et il semble que cela touche aux devis, au travail du client et à l'approbation du client, aux tests et au travail d'assurance qualité, au travail de développement et au travail de conception. Et on dirait qu'il y a un changement. Et il semble qu'il y ait un changement positif. Y a-t-il quelque chose-

Donc, si vous avez un client qui vient et qu'il dit, j'ai des exigences xyz. Quel ensemble d'exigences entendriez-vous qui vous ferait dire que c'est parfait pour un projet Headless ? Et Stephen, pouvez-vous commencer ?

STEPHEN BROOKS : Oui, bien sûr. Donc, la première chose que je regarde personnellement est l'empreinte de sécurité dont l'organisation a besoin, n'est-ce pas. S'agit-il d'un site Web interne ou d'un site Web externe ? Après cela, nous commençons à examiner, hé, est-ce que ce CMS va alimenter plusieurs éléments, une livraison omnicanale. Si ces deux premières cases sont cochées, boum, c'est une construction sans tête automatique.

Si un seul de ces éléments est coché, nous devons alors discuter un peu plus en profondeur avec notre client pour nous assurer que cela correspond à son empreinte opérationnelle. Et je tiens à dire que 95 % des conversations que j'ai eues au cours des huit derniers mois ont toutes été cool. Tout le monde aime ça. C'est un véritable changement de paradigme par rapport à tout le reste. Donc voilà.

HASHIM WARREN : Non, c'est génial. Et Jonathan, pouvez-vous en parler un peu? Quel ensemble d'exigences vous donnerait l'impression, OK, cela devrait être un projet Headless ? Et aussi quels compromis expliqueriez-vous à un client concernant l'adoption de Headless ?

JONATHAN JETER : Bien sûr, donc l'un des principaux, un peu plus tôt, est le nombre de sources de données que vous utilisez pour agréger le contenu du site ? Et le client veut-il l'utiliser comme référentiel de contenu central, par opposition à cela et aux huit autres sources dont il dispose pour son application mobile ou pour ses médias, ou pour quoi que ce soit d'autre, n'est-ce pas ?

Nous avons donc cette conversation. S'ils sont comme, oh ouais, nous sommes tous dedans. Et c'est un choix évident. De plus, en tant qu'agence de publicité, nous avons ces types de créatifs qui conçoivent toujours ces choses vraiment folles, n'est-ce pas. Donc, si nous savons à l'avance comme, oh, qui est la création, parfois cela suscite une conversation, nous savons que cela sera plus facile à développer en tant qu'application React qu'à essayer de personnaliser ce thème dans WordPress.

Mais les échanges. L'un est le prix. C'est plus cher, c'est l'entretien, non. Alors maintenant, vous ne vous contentez pas de maintenir WordPress, c'est vrai, vous maintenez deux piles différentes, deux applications différentes. C'est pourquoi nous avons emprunté cette voie, et nous utilisions tout AWS et Gatsby, et tout ce genre de choses pour le faire à l'avance. Et donc, nous étions tous là quand Atlas est arrivé. Nous étions comme, oh ouais, si nous pouvions faire tout cela en un seul endroit.

Parce que pendant des années, nous avons parlé à notre moteur WP, où j'étais comme, vous devez le faire parce que nous le faisons ailleurs, d'accord. Alors rassemblons tout cela ensemble. Nous étions donc ravis de cela. Vraiment, vraiment content du processus de construction des chantiers à Atlas. Mais le compromis est essentiellement la maintenance, qui disparaît avec Atlas. Le coût pour le client, en ce qui concerne l'hébergement, par opposition à un simple site WordPress standard.

Mais parfois, comme je l'ai déjà dit, ce coût de développement du site diminue, le coût de maintenance du site diminue. C'est donc un compromis.

JAMES SQUIRES : Je pense qu'une autre chose très importante que nous considérons lorsque nous débattons de la pertinence d'une approche thématique ou Headless, c'est à quoi ressemble le transfert après la création d'un site ? Le client s'attend-il à ce qu'il dispose de ressources internes qui s'en chargent ? Ou recherchent-ils une agence partenaire à long terme sur laquelle compter ?

Et c'est une décision vraiment critique, parce que si vous avez une équipe qui n'est pas familière avec, disons, React, Gatsby ou Next, quelle que soit la pile Headless, cela pourrait être une assez grosse surprise s'ils ne sont pas familiers avec le Architecture sans tête, et comment cela va être maintenu. C'est donc quelque chose de vraiment important, cela peut sembler évident, mais juste pour être explicite, OK, une fois que cette chose sera lancée, et que nous serons en mode maintenance et transferts, quel est le plan là-bas ?

HASHIM WARREN : Génial.

TAYO ONABULE : Je pense que l'autre chose qui est, je pense que Jonathan l'a mentionné peut-être, est en quelque sorte le fait que quoi, et c'est en grande partie ce sur quoi nous nous concentrons en tant qu'agence, ce qui est activé par Headless est principalement une expérience chose. En termes de ce avec quoi vos utilisateurs interagissent. Et si souvent, et c'est une conversation changeante pour chaque entreprise. Certaines entreprises veulent juste faire le travail. Certaines entreprises veulent être flashy à ce sujet.

Et dans tous les cas où il est important pour le client d'avoir une expérience vraiment révolutionnaire, ou quelque chose de vraiment à la pointe en termes de performances, ou s'il a besoin de quelque chose qui est considérablement plus engageant dans la compétition, alors toutes ces choses sont beaucoup, beaucoup plus faciles à faire sur Headless. Et donc la conversation dans mon esprit, ou du moins l'angle par lequel nous avons tendance à partir, est juste - est-ce que vous devez le faire ou est-ce que vous devez le faire et impressionner beaucoup les gens avec.

Parce qu'évidemment, WordPress le fait depuis longtemps, et c'est un endroit solide pour construire un site, mais en gros, combien de « flashy flashy » voulez-vous ? Et si vous en voulez beaucoup, alors Headless est un très bon moyen de

HASHIM WARREN : C'est génial. Jimmy, je veux parler de dotation en termes d'agence. Quand vous pensez aux projets Headless, voulez-vous des développeurs WordPress qui ont adopté JavaScript et, disons, quelque chose comme React ? Ou préférez-vous plutôt un développeur JavaScript qui n'utilise même pas WordPress ? Comment pensez-vous de la dotation en personnel en ce qui concerne les projets Headless WordPress ?

JAMES SQUIRES : Oui, c'est une bonne question. Notre agence, nous recherchons React comme une sorte de référence de base, donc évidemment JavaScript et expérience dans le cadre React. C'est en quelque sorte notre obligation, à tous les niveaux, vraiment. WordPress est - nous traitons cela comme un "agréable à avoir". C'est quelque chose, surtout dans l'espace Headless, que nous pouvons former assez rapidement.

Je veux dire, d'une manière générale, avec Headless, vous passez votre temps dans WordPress à développer des types de publication personnalisés et à simplement mettre en place le cadre de composants d'un point de vue backend, mais vous ne touchez pas beaucoup à l'héritage, genre d'aspects thématiques dans une architecture Headless normale. Nous avons donc constaté que nous n'avions vraiment pas besoin de cette expérience WordPress vraiment essentielle.

Bien sûr, nous avons besoin de certains joueurs dans l'équipe qui ont cela pour certains aspects, mais dans l'ensemble, nous avons vraiment réussi à attirer, disons, un ingénieur React, qui n'a jamais touché WordPress auparavant. Montrez-leur comment apporter des modifications aux champs, et ils sont prêts à fonctionner. Ils comprennent déjà GraphQL, qui est une compétence de base avec laquelle vous devez vous familiariser avec les architectures Headless.

Mais au-delà de cela, la connaissance de WordPress peut être plutôt superficielle, et vous pouvez faire participer quelqu'un et être très productif sur un projet. C'est la beauté avec les composants React, c'est que n'importe quel développeur React peut sauter au milieu d'un projet, regarder mon dossier de composants, et nous leur en attribuons un, et ils partent pour les courses tant qu'ils ont leur structure de données déjà définie.

HASHIM WARREN: C'est aussi très intéressant, en termes de possibilité de séparer le travail. Vous travaillez sur ce composant, et vous pouvez travailler dessus séparément du projet. C'est un très bon exemple.

Jonathan, qu'en pensez-vous en ce qui concerne les projets Headless WordPress ? Préférez-vous avoir un développeur WordPress dont les compétences – qui ajoutent React à cela, ou n'importe quel framework JavaScript à leur ceinture ? Ou un développeur JavaScript qui évolue sur WordPress, qu'en pensez-vous ?

JONATHAN JETER : Donc, comme l'a dit Jimmy, nous avons besoin des deux, mais nous allons en chercher plus maintenant sur React, View, les développeurs JavaScript front-end. Eh bien, tout le monde s'appelle Full Stack maintenant, mais les développeurs JavaScript vont pouvoir intervenir. Et j'ai eu des développeurs qui sont venus et ont dit, oh, je ne vais pas travailler dans WordPress, comme si ce n'était pas quelque chose Je veux faire. Et une fois qu'on s'y met, on fait un projet Headless, oh, c'est pas si mal.

Parce qu'ils ne s'occupent pas de tout le travail pour le PHP et tout ça. Mais en même temps, nous avons en fait déplacé certaines de nos personnes DevOps pour gérer le backend WordPress, donc nous n'avons pas nécessairement besoin d'un développeur backend pour le faire, donc ça marche très bien. Poursuivre.

JAMES SQUIRES: J'allais ajouter à cela, du moins d'après notre expérience, le nombre d'ingénieurs que vous pouvez intégrer à un projet Headless et être productif a tendance à être beaucoup plus élevé. Par exemple, nous venons de lancer un Headless basé sur SvelteKit – je pense que c'est le premier sur Atlas – la semaine dernière. Je ne recommande pas encore SvelteKit aux clients, mais nous l'aimons un peu.

Mais nous avions un excès de huit ingénieurs travaillant simultanément sur des composants, et avec le développement basé sur des thèmes, nous avons tendance à avoir plus de mal à recruter beaucoup d'ingénieurs et à être productifs. Juste parce que les choses sont un peu plus monolithiques, en termes de combien de choses pouvez-vous toucher à la fois. Je suis sûr que c'est possible, et vous pouvez le coordonner, mais nous trouvons que c'est beaucoup plus facile sur les architectures Headless.

HASHIM WARREN : C'est une belle vue, soit dit en passant. J'ai vu le lancement. C'est un beau site.

JAMES SQUIRES : Merci.

JONATHAN JETER : L'autre chose que je dirais également, c'est que je sais que nous ne parlons que de WordPress, d'accord, mais nous traitons également de projets qui ne sont pas WordPress, d'accord. Ainsi, ces développeurs JavaScript peuvent travailler sur plusieurs systèmes backend, contrairement à si j'embauche un développeur .net, ils ne fonctionnent, pour la plupart, que dans .net, n'est-ce pas.

Nous avons donc les personnes qui s'assurent que les API fonctionnent, agrégent les données, rassemblent tout cela, d'accord. Et puis nous avons les frontaux qui peuvent travailler sur n'importe lequel de ces projets, au lieu d'être spécifiques à une langue spécifique.

TAYO ONABULE : Et je pense qu'il y a quelques petites choses ici que nous mentionnons tous. Je pense, disons-le comme c'est, comme React, un– Dans notre cas, nous avons tendance à nous en tenir à React de toute façon. Nous avons quelques développeurs View, mais nous avons tendance à nous en tenir à React. Mais tous ces frameworks frontaux ont été conçus spécifiquement avec le type de développeur et de processus à l'esprit. Ils sont conçus - j'imagine que M. Facebook à un moment donné était comme, assurons-nous que c'est aussi efficace que possible pour notre équipe.

Et donc, c'est au cœur de ce qu'est React, et ce sera à peu près la même chose pour View et Angular. En ce qui concerne le côté WordPress, encore une fois, appelez-le comme il est. Essentiellement, vous pourriez vous débrouiller en sachant simplement comment naviguer dans le backend WordPress et en utilisant ACF. Et sinon, n'avez aucune connaissance de WordPress et parvenez toujours à créer un site WordPress Headless.

Et donc l'exigence du côté de WordPress, à moins que vous n'essayiez de faire des choses qui commencent à devenir compliquées, vous pouvez techniquement créer un site WordPress sans tête avec essentiellement une connaissance de l'emplacement du fichier de fonctions .php et rien d'autre. Vous pouvez vous débrouiller. Et je pense que la beauté de tout cela est, comme Jonathan l'a dit, encore une fois, que ces développeurs JavaScript vont être utiles dans tous vos projets. Et je pense qu'il est assez sûr de dire que dans un avenir prévisible, le Web sera axé sur JavaScript, et c'est donc un talent très utile.

À quelle distance de la ligne ce dernier interrupteur, cela prendra probablement un certain temps. Donc c'est honnêtement, ce n'est pas vraiment un gros engagement en quelque sorte. C'est celui qui a du sens que j'imagine la plupart des cas.

HASHIM WARREN : Je veux juste étayer votre histoire car dans une vie antérieure, j'ai dû former deux développeurs React sur notre nouveau site WordPress. Et c'était un site WordPress sans tête. Et ce n'était qu'un après-midi. Je leur ai montré ACF, ils étaient vraiment excités, ils ont créé les modèles de données et ils étaient partis. Et même l'un des développeurs a en fait connecté l'éditeur classique et a fait en sorte que je puisse contrôler certains composants sur le front-end.

C'est avant Gutenberg, donc nous utilisions des champs de répéteur et ACF, et contrôlions certains des composants sur le front-end. C'était incroyable. Mais les deux développeurs React l'ont immédiatement compris. Il leur a juste fallu l'après-midi et ils sont partis pour les courses.

TAYO ONABULE : Le problème, c'est qu'avec ce genre de développeurs front-end, ils sont assez habitués à se connecter à des back-ends pour leurs données et à avoir une structure de données à laquelle s'en tenir. C'est un élément commun de leur flux de travail, donc WordPress ne fait pas beaucoup de chances.

JONATHAN JETER : Avec la prévalence de - désolé, la prévalence du SaaS, les applications étant disponibles partout maintenant, les choses que vous faisiez dans WordPress, que ce soit le commerce électronique, que ce soit l'intégration avec le CRM, tout ce genre de choses. Maintenant, ce n'est pas fait dans - cela n'a plus besoin d'être fait sur WordPress. Vous n'avez pas besoin d'installer un plug-in Marketo ou un plug-in Salesforce, ou quelque chose pour essayer de les connecter, n'est-ce pas.

Maintenant, vous faites ces connexions vous-même, ce qui permet une meilleure expérience, une expérience personnalisée. Cela permet la vitesse, la sécurité, toutes ces choses, au lieu d'essayer de faire appel à un développeur PHP pour comprendre comment faire fonctionner ces choses dans WordPress.

HASHIM WARREN : Génial. Stephen, j'aimerais avoir de vos nouvelles sur l'écosystème, l'écosystème JavaScript. Je sais que les développeurs WordPress sont habitués à un écosystème vraiment génial et robuste, en termes de plugins, également de communauté. Pouvez-vous nous dire comment cela se compare peut-être à l'écosystème du monde JavaScript ? À la fois en termes de technologie et même de communauté.

STEPHEN BROOKS : Oui, donc avec WordPress, il a le plus grand marché de plug-ins pour la construction monolithique traditionnelle. Mais revenons au point de Jonathan il y a juste une seconde, avec l'utilisation de NPM pour toutes vos fonctionnalités dont vous avez besoin depuis le front-end, c'est équivalent, sinon supérieur, au marché WordPress. Parce que non seulement vous avez tous ces packages NPM disponibles. Il existe également de nombreux STK que vous pouvez également utiliser pour créer très rapidement toutes les intégrations de données dont vous avez besoin.

Je dirais donc presque qu'il est supérieur d'environ 20 %. Il suffit de lancer un nombre arbitraire, mais il est beaucoup plus rapide pour les gens de se déplacer. Et beaucoup de choses sur le NMP sont pertinentes. Vous n'avez pas non plus à vous soucier des incompatibilités de version de base de WP et de version de plug-in qui peuvent survenir. Une fois que vous avez épinglé vos versions dans le manifeste de votre package, je veux dire que vous avez terminé. Vous n'avez plus vraiment à vous soucier de les mettre à jour si vous ne le souhaitez pas ou quelque chose comme ça.

Encore une fois, cela revient à ce que tout le monde dit, la vitesse et la flexibilité sont primordiales lors de l'utilisation de la solution Headless par opposition à l'approche WordPress traditionnelle.

JAMES SQUIRES : Ne pas jeter d'ombre sur les entreprises qui gagnent beaucoup d'argent avec leurs plugins WordPress, mais c'est un autre domaine car vous avez juste tendance dans une architecture sans tête à avoir moins de coûts de licence, alors que dans un thème typique, il y a de très bons plugins que nous nous retrouvons toujours à transformer en propositions d'achat et d'utilisation. Pour la plupart, tout dans NPM est un logiciel gratuit et open source.

Il y en a certainement certains qui peuvent avoir un modèle de service qui leur est associé. Mais d'une manière générale, vous pouvez trouver la solution la plus populaire, et c'est la licence open source. Il est donc facile d'agir rapidement de cette façon et de ne pas le ralentir avec les approbations des clients sur les coûts de licence et des choses comme ça.

HASHIM WARREN : Jimmy, j'ai un autre exemple qui ressemble à ça. Je construisais donc un site Web Gatsby et j'y ajoutais Google Analytics. Gatsby a un écosystème de plugins, tous les plugins sont open source. Leurs packages sont sur NPM, ils sont faciles à installer. J'ajoute donc Google Analytics, et il y avait toutes ces options qui, avec le plugin Google Analytics le plus populaire pour WordPress, certaines de ces options vont dans la version premium. J'étais donc très excité en tant que quelqu'un qui est heureux de payer pour ce plug-in WordPress pour avoir la même fonctionnalité avec ce package qui était aussi un plugin Gatsby. Je suis vraiment excité de voir à quel point ces écosystèmes correspondent.

TAYO ONABULE : Je pense que c'était aussi très rapide sur tout le sujet du NMP. Je pense que ce n'est qu'une infime chose, et c'est probablement sans conséquence, mais moi pour moi. Je préfère de loin le fait que lorsque vous développez quelque chose dans React, vous voulez quelque chose, vous le téléchargez via CLI. Et vous n'avez pas besoin d'aller dans WordPress, ou tout autre type de gluant, c'est juste là dans votre espace. Vous n'avez pas à quitter le studio, et tout est là. Et c'est un processus beaucoup moins compliqué que de faire des recherches, de trouver un plug-in, de l'installer, etc. Je n'ai jamais été fan de ça.

HASHIM WARREN : Génial. Jonathan, je veux vous demander, nous avons parlé des exigences qui vous feraient dire que c'est parfait pour Headless WordPress. Quel type de projet vous ferait sentir que c'est, OK, cela devrait être un projet WordPress traditionnel.

JONATHAN JETER : Nous en faisons donc beaucoup aussi, n'est-ce pas ? Parfois c'est budgétaire. Ils arrivent et disent, nous en avons beaucoup. Nous sommes comme, il n'y a pas le choix, à droite. C'est ce que nous faisons, n'est-ce pas. Et parce que, alors nous avons des choses que nous utilisons. Ce processus et ce système sont déjà en place. Comme Jimmy le disait, nous avons des plug-ins que nous intégrons à chacune de ces propositions parce que nous savons que c'est très simple.

Donc, un site de petite marque typique. Typique - Comme Tayo le disait plus tôt, il n'est pas nécessaire que ce soit flashy, n'est-ce pas. Il n'y a rien d'outrageusement créatif sur ce site porno, n'est-ce pas. Et ils sont juste allés, hé, nous les avons déjà eus, comme si nous savions que nous avions besoin d'un site Web, alors faites-en un. Droite. Et si tel est le cas, alors, oui, absolument, en fonction de votre budget et des exigences, un site WordPress standard fera l'affaire.

Nous sommes même arrivés au point où, en utilisant Genesis, et Genesis Pro, et Smart Plugin Manager, et toutes ces sortes de choses, nous avons des sites que nous construisons que les développeurs ne touchent même pas. Cela passe simplement par le processus, et le processus de création, le studio édite les fichiers, et ils mettent essentiellement le contenu. Nous avons des éditeurs qui le vérifient et mettent le contenu, et le site est fait sans qu'un développeur ne touche jamais il.

Et c'est un peu comme ça qu'il faut faire, pour gagner de l'argent sur ces projets, parce qu'avec ce genre de budget, on ne peut pas avoir 20 heures de développement sur le back-end d'un de ces sites. C'est donc généralement ainsi que nous décidons, à moins que ce ne soit un site énorme, mais ils sont comme non, non, non, nous ne voulons rien de compliqué. Nous voulons juste que ce soit un site régulier. Nous avons fait cela, juste beaucoup de contenu, des blogs, ce genre de choses.

En termes de référencement, WordPress est toujours excellent. Si c'est ce qu'ils recherchent, c'est comme si nous nous moquions de son apparence. Nous voulons juste la fonction. Nous voulons que ce soit rapide. Nous voulons avoir du contenu et un bon classement. Un site WordPress traditionnel fonctionne bien.

HASHIM WARREN : Génial. Stephen, peut-il en parler ? When would you say, OK, this needs to be a traditional site or traditional WordPress site?

STEPHEN BROOKS: It really follows along with Jonathan. Cost is going to be the first one, and then the second one after that is going to be time to market. If somebody needs something out pretty quick, even with the accelerator as John's talking about in terms of Genesis blocks, and just having a block catalog that you can do 0 dev from, it's still really incumbent on getting that stuff out as quickly as possible for those clients. Also to spin outs is a pretty big one for us. To where, hey, we need some sort of marketing presence for our investors. This is going live in two weeks. What could you do for me.

HASHIM WARREN: Awesome Thank you so much to our panel for your participation today. If you are interested in Headless WordPress, you can get a free Atlas Sandbox account at WPEngine.com/Atlas. And compare for yourself. You can use an all-in-one WordPress site, and compare it right against a Headless WordPress site, to compare everything that we talked about today. Thank you so much for joining us.