DE{CODE}: Quando scegliere Headless per i clienti

Quando un cliente ha requisiti di prestazioni e sicurezza, quando un'agenzia dovrebbe scegliere WordPress tradizionale o WordPress headless per il lavoro? Scopri di più in questa sessione DE{CODE}, con un panel di esperti di agenzie che valutano i vantaggi, i vincoli, le opportunità e i compromessi dell'andare senza testa.

Slide della sessione

Trascrizione del testo completo

HASHIM WARREN: Ciao, benvenuto al nostro panel, Quando scegliere WordPress headless per i clienti. Quindi mi chiamo Hashim Warren e sono il Product Marketing Manager per Atlas, la nostra soluzione per Headless WordPress. E una delle prime domande che ho ricevuto dalle persone quando stanno adottando, o vogliono adottare Headless WordPress, è quando dovrei usare WordPress tradizionale, tutto in un WordPress, e quando dovrei usare Headless WordPress.

Quindi, se ho un cliente che ha requisiti di prestazioni e sicurezza, ad esempio cosa dovrei pensare in termini di adozione o scelta di Headless o WordPress tradizionale. E inoltre, se scelgo Headless WordPress, cosa dovrei aspettarmi, in cosa mi sto cacciando qui. Quindi oggi abbiamo un panel eccellente con esperienza sia con progetti WordPress tradizionali che con progetti WordPress senza testa che sarà in grado di rispondere ad alcune delle grandi domande che so che molti di voi hanno.

Quindi oggi con me abbiamo, Jonathan Jeter, che è il direttore della produzione tecnica presso Click Here Labs. Abbiamo anche Stephen Brooks, il direttore della tecnologia di Springbox. Abbiamo anche James Squires, il Chief Technology Officer presso lo spazio 150. E abbiamo anche Tayo Onabule, l'amministratore delegato di Drawl.

Quindi voglio solo portare il pannello in questo momento, così possiamo iniziare con questa conversazione. Quindi diamo il via alla conversazione in questo modo. Dimmi solo cosa ti ha fatto interessare personalmente, o la tua agenzia, a Headless WordPress in primo luogo. E Jonathan, puoi iniziare?

JONATHAN JETER : Certo. Quindi siamo stati interessati a lavorare nello spazio Headless per un po'. E il motivo principale per cui eravamo interessati era perché volevamo creare progetti più grandi che integrassero dati da più fonti. E l'API di WordPress non era ancora del tutto lì. Quindi stavamo lavorando su diversi modi per presentare il livello front-end, utilizzando ancora il contenuto di WordPress. E quindi, questo è fondamentalmente quello che abbiamo fatto per circa cinque o sette anni, cercando di capire quale fosse il modo migliore per farlo.

E ora è molto più facile di prima, ovviamente c'è molto di più, c'è una vasta gamma di opzioni per quanto riguarda il modo in cui lo farai. E così, abbiamo visto crescere lo spazio e siamo davvero entusiasti di dove sta andando. Esso

HASHIM WARREN: Fantastico. E Stephen, hai una storia simile? Ad esempio, cosa ha reso te o la tua agenzia interessata a Headless WordPress?

STEPHEN BROOKS : Sì, quindi siamo nello spazio Headless dal 2015 circa, occupandoci tradizionalmente di piattaforme CMS basate su jam. Negli ultimi anni, è stato impegnativo trattare con alcuni team di marketing che lavorano all'interno di un sistema jam, proprio a causa del cambio di paradigma nell'inserimento dei contenuti, al contrario di un approccio basato sul tipo di post e pagina.

Abbiamo anche provato, proprio come Jonathan, a sfruttare l'API di WordPress. È un po' ingombrante, non ti dà sempre esattamente ciò di cui hai bisogno. Ogni volta che WP Engine ha menzionato Atlas e ha parlato delle tecnologie sottostanti, è stato il bacio dello chef con ciò che abbiamo tradizionalmente fatto nello spazio della marmellata.

Quindi ora è una conversazione davvero facile con i nostri clienti, perché quasi tutti i marketer hanno esperienza di lavoro all'interno di WordPress, ma gli sviluppatori ottengono l'ulteriore vantaggio di una soluzione Headless. In questo modo ottieni la mitigazione dei rischi per la sicurezza, così come solo alcune delle migliori interazioni con un livello di presentazione basato su React. Quindi questo è stato il nostro vero driver qui di recente.

HASHIM WARREN: È fantastico. Tayo, puoi raccontarci la tua storia e, giusto per proseguire, puoi parlarci di come convincere gli editori ad adottare Headless WordPress?

TAYO ONABULE : Sì. Voglio dire, penso che, nel nostro caso, abbiamo avuto un ingresso leggermente più recente e un po' diverso nello spazio Headless WordPress. Uno dei driver principali per noi è uno dei nostri clienti Android Authority, che ha una portata abbastanza ampia. In un certo senso, al momento attuale, si accenna a circa 20 milioni di visitatori mensili.

E i loro bisogni sono abbastanza semplici in un certo senso. Hanno bisogno di un SEO davvero eccezionale, come il livello superiore. E hanno molti concorrenti molto competenti intorno a loro. Quindi sì, SEO davvero eccezionale, prestazioni davvero eccezionali ed esperienza di lettura davvero eccezionale per tutti gli articoli che pubblicano.

Quindi Headless è stato davvero– è nato davvero per noi come parte della conversazione proprio mentre stavamo cercando di fare tutto il possibile per trovare un modo per fare in modo che i loro siti WordPress esistenti soddisfino tutte queste esigenze. Davvero al massimo, insomma. E Headless, prima era il caso di me che facevo solo delle ricerche e dicevo, oh, beh, forse potremmo, forse provarci.

E ci siamo approfonditi sempre di più, e abbiamo attraversato il processo per convincere la squadra. Ma man mano che ci addentravamo nell'intero sviluppo, abbiamo iniziato a renderci conto che, sì, rispondeva a tutte quelle domande principali, come le prestazioni SEO e l'esperienza, ma ci ha anche dato una flessibilità completa su tutta la linea con il passare degli anni SU.

Abbiamo lanciato, credo fosse maggio dell'anno scorso, quindi in realtà stiamo arrivando all'anniversario di quello. , Ma sì, da quel lancio siamo riusciti a creare un numero enorme di integrazioni nel sito. Tutto ciò sarebbe stato notevolmente più difficile se fossimo stati su WordPress monolitico o tutto in uno. Quella flessibilità che ti dà è una specie di– è una delle cose che stavo dicendo ad Android Authority che avremmo avuto, ma non credo di essermi reso conto della portata e della libertà che fornisce, fondamentalmente.

HASHIM WARREN: È fantastico. Quindi, finora abbiamo sentito parlare di prestazioni SEO, flessibilità per gli sviluppatori, flessibilità in termini di tipo di progetto, inoltre gli editori sono in grado di attenersi a un CMS che conoscono. Jimmy, la tua esperienza corrisponde a qualcosa di tutto ciò o hai qualcosa da aggiungere in termini di ciò che ha attratto te o la tua agenzia da Headless WordPress?

JAMES SQUIRES: Sì, penso che anche molte di quelle cose che condividiamo siano in comune. L'unica cosa che probabilmente aggiungerei che forse si imbatterà è un po' egoista all'inizio, ma in un certo senso ci arriverò e perché è una buona cosa. Ma davvero per noi, è stato davvero guidato dalla soddisfazione degli sviluppatori.

Provenivamo principalmente da un background di framework basato su React e React, una specie di ingresso in WordPress. E i nostri clienti chiedevano WordPress sempre di più, ma i nostri ingegneri non sono davvero così soddisfatti dello sviluppo basato su temi per la maggior parte. Lo facciamo ancora quando ci sono ancora applicazioni in cui ha molto senso, ma se voi sviluppatori siete soddisfatti del prodotto e di ciò che stanno costruendo, trovo che l'output sia spesso un'esperienza stellare in modo che lì è un vero vantaggio per i nostri clienti, anche se in un certo senso il nostro salto in esso era incentrato su qualcosa che i nostri ingegneri volevano fare.

HASHIM WARREN: È fantastico. Una delle cose che molte persone che stanno guardando questo avranno sentito nelle conferenze, la differenza tra lo sviluppo basato su temi per WordPress e lo sviluppo basato su componenti. Qualcuno può parlarne? I vantaggi dell'adozione di un approccio basato sui componenti durante la creazione di siti Web?

TAYO ONABULE: Sì, mi piacerebbe davvero entrare in questo, in realtà. Allo stesso modo, sono sicuro che tutti abbiamo esempi di questo, ma penso che una delle cose più soddisfacenti che accadono quando lavori con le librerie JavaScript, come quelle di React, nella nostra esperienza comunque, è sì, come dici tu, accesso a questo tipo di stile di costruzione basato su componenti.

E significa che da una parte, puoi suddividere un intero progetto del sito in queste parti componenti che sono molto più flessibili. Diciamo, ad esempio, che potresti avere un blocco su una pagina con due stili diversi. Uno, dove l'immagine è sul lato sinistro e il testo è sul lato destro, diciamo. Proprio come una sorta di semplice esempio. E React, questo è il caso in cui hai un blocco con un modificatore, essenzialmente, per dire semplicemente, capovolgi l'ordine del testo e dell'immagine.

Quando parliamo di monolitico, sei essenzialmente solo, sì, forse inizi sulla stessa base, ma molto velocemente devi solo separare le due cose, e ora hai due cose separate. E i cambiamenti, in una certa misura, devono essere distribuiti su due cose separate. Ed è quel tipo di concetto che significa che man mano che si entra in usi su scala sempre più ampia per i front-end Headless, quella flessibilità e coerenza che si possono avere su un intero sito, attraverso tutti gli usi di un particolare componente, significano che lo sviluppo , come ha detto James in precedenza, è molto più soddisfacente per gli sviluppatori.

È un'esperienza notevolmente più piacevole. Puoi davvero dire che React è stato progettato per massimizzare l'output degli sviluppatori, ed è ed è che, ancora una volta come dice James, tutto ciò viene trasmesso al cliente. Perché penso che tu possa dire quando qualcosa è stato fatto con amore e divertimento, si traduce sempre in un risultato migliore.

STEPHEN BROOKS: Sì, non solo quello, Tayo. Ma ci sono anche altri grandi vantaggi. Voglio dire, hai davvero colpito in testa per il pezzo di soddisfazione dello sviluppatore, ma se dai un'occhiata allo sviluppo tradizionale basato su modelli, al contrario di uno sviluppo basato su componenti, unit test, giusto. È davvero difficile implementare qualsiasi tipo di unit test all'interno di un approccio basato su temi. Con un componente, boom, è proprio lì per te.

Ma voglio aggiungere un punto a questo, ma non è necessariamente per gli sviluppatori, lo è di più per gli imprenditori. In genere con un approccio basato sui componenti, il tuo livello di impegno diminuisce in modo significativo rispetto a una determinata pagina del tema, perché i tuoi componenti li riutilizzerai ovunque, giusto. E non richiede un ulteriore tempo di digitazione, digitazione, per aggiungere quel blocco aggiuntivo ovunque vada. Lo costruisci solo una volta. Ogni volta che lo consumi, idrati la tua corporatura. Bum, hai finito. È così bello, così veloce. È meraviglioso.

JONATHAN JETER: E abbiamo dovuto formare il nostro staff creativo, giusto, perché sono così abituati a dire, OK, questo sito è composto da 5 modelli, o questo è qualunque cosa. Siamo tipo, no, no scappare da quello, giusto. E così abbiamo finito per chiamarlo. Basta progettare la pagina del lavello della cucina, giusto, una pagina con tutto sopra, giusto, e la costruiremo da lì. Quindi sì, ha reso lo sviluppo molto più semplice, ma abbiamo dovuto formare lo staff su tutta la linea per assicurarci che capissero cosa stiamo facendo e come lo stiamo costruendo.

JAMES SQUIRES: Sì, anche nelle operazioni. Voglio dire, è cambiato il modo in cui vengono modellate le nostre proposte per i clienti quando lo facciamo. Parliamo di quantità di blocchi e di come li stiamo costruendo, al contrario dei modelli. E questo è proprio un tale cambio di paradigma, penso, per alcuni, specialmente dal punto di vista del marketing, a cui pensare: hai infinite pagine di diversi tipi di blocchi. Sono davvero questi blocchi e componenti fondamentali e ciò che stiamo costruendo e individuando.

TAYO ONABULE: E solo un ultimo pezzo su questo. E penso che la menzione delle proposte sia davvero un buon punto, perché il processo Headless cambia in modo massiccio qualsiasi stima che potresti avere su ciò che una funzionalità impiegherà o un nuovo layout di pagina. Il fatto è che diminuisce in modo molto consistente nel tempo. Più ampia è la tua libreria di componenti, meno ci vuole per aggiungere uno stile aggiuntivo o qualcosa del genere, modificare uno stile in tutto il sito, aggiungere un nuovo layout di pagina. Tutte queste cose diventano sempre più facili.

E penso che sia gratificante per tutti, a dire il vero.

HASHIM WARREN: Quindi, è davvero interessante. Non è solo Headless rispetto a un sito tutto in uno, è sviluppo basato su modelli rispetto a componenti. E sembra che tocchi il preventivo, il lavoro del cliente e l'approvazione del cliente, i test e il lavoro di QA, il lavoro di sviluppo e il lavoro di progettazione. E sembra che ci sia un cambiamento. E sembra che ci sia un cambiamento positivo. C'è qualcosa-

Quindi, se hai un cliente che entra e dice, ho requisiti xyz. Quale insieme di requisiti sentiresti che ti farebbe dire che è perfetto per un progetto Headless? E Stephen, puoi iniziare?

STEPHEN BROOKS: Sì, certo. Quindi la prima cosa che guardo personalmente è l'impronta di sicurezza di cui l'organizzazione ha bisogno, giusto. Si tratta di un sito Web rivolto all'interno o di un sito Web rivolto all'esterno? Dopodiché, iniziamo a dare un'occhiata a, ehi, questo CMS alimenterà più articoli, consegna omnicanale. Se quelle prime due caselle sono spuntate, boom, è una build Headless automatica.

Se solo uno di questi viene spuntato, allora dobbiamo parlare un po' più a fondo con il nostro cliente per assicurarci che sia in linea con il suo footprint operativo. E voglio dire che il 95% delle conversazioni che ho avuto negli ultimi otto mesi è stato tutto interessante. Piace a tutti. È un vero cambio di paradigma rispetto a tutto il resto. Quindi sì.

HASHIM WARREN: No, è fantastico. E Jonathan, puoi parlarne un po'? Quale insieme di requisiti ti farebbe sentire, OK, questo dovrebbe essere un progetto Headless? E anche quali compromessi spiegheresti a un cliente sull'adozione di Headless?

JONATHAN JETER: Certo, quindi uno dei principali, un po 'al punto prima, è quante fonti di dati stai usando per aggregare il contenuto per il sito? E il cliente vuole usarlo come repository centrale dei contenuti, al contrario di questo e delle altre otto fonti che hanno per la loro app mobile o per i loro media, o per qualsiasi altra cosa, giusto.

Quindi abbiamo quella conversazione. Se dicono, oh sì, siamo tutti dentro. E questa è una scelta ovvia. Inoltre, come agenzia pubblicitaria abbiamo questi tipi creativi che progettano sempre queste cose davvero folli, giusto. Quindi, se sappiamo in anticipo come, oh, chi è la creatività, a volte questo richiede una conversazione, sappiamo che sarà più facile da sviluppare come app React piuttosto che provare a personalizzare quel tema su Wordpress.

Ma i compromessi. Uno è il prezzo. È più costoso, è manutenzione, giusto. Quindi ora non stai solo mantenendo WordPress, giusto, stai mantenendo due diversi stack, due diverse applicazioni. Questo è il motivo per cui abbiamo intrapreso quella strada e stavamo usando tutto AWS e Gatsby e tutte queste cose per farlo in anticipo. E così, eravamo all in quando Atlas si è presentato. Eravamo tipo, oh sì, se possiamo fare tutto questo in un unico punto.

Perché per anni abbiamo parlato con il nostro WP Engine, dove ero tipo, voi ragazzi dovete farlo perché lo stiamo facendo da qualche altra parte, giusto. Quindi mettiamo tutto insieme. Quindi ne eravamo entusiasti. Davvero, davvero contento del processo di costruzione dei cantieri in Atlas. Ma il compromesso è fondamentalmente la manutenzione, che se ne va con Atlas. Il costo per il cliente, per quanto riguarda l'hosting, rispetto a un semplice sito WordPress standard.

Ma a volte, come ho detto prima, il costo di sviluppo del sito diminuisce, il costo di manutenzione del sito diminuisce. Quindi è un compromesso.

JAMES SQUIRES: Penso che un'altra cosa davvero importante che consideriamo quando discutiamo se sia appropriato per un approccio basato su temi o Headless, è come appare il trasferimento dopo la creazione di un sito? Il cliente si aspetta di avere risorse interne che se ne occupino? O stanno cercando un partner di agenzia a lungo termine su cui fare affidamento?

E questa è una decisione davvero critica, perché se hai una squadra che non ha familiarità con React, Gatsby o Next, qualunque sia lo stack Headless, allora potrebbe essere una bella sorpresa se non hanno familiarità con il Architettura senza testa e come verrà mantenuta. Quindi è qualcosa di veramente importante, potrebbe sembrare ovvio, ma solo per essere espliciti, OK, una volta che questa cosa si avvia, e siamo in modalità manutenzione, e passaggi di consegne, qual è il piano lì?

HASHIM WARREN: Fantastico.

TAYO ONABULE: Penso che l'altra cosa che sia, penso che Jonathan l'abbia menzionata forse, sia il fatto che cosa, e questo è in gran parte ciò su cui ci concentriamo come agenzia, ciò che è abilitato da Headless è principalmente un'esperienza cosa. In termini di ciò con cui interagiscono i tuoi utenti. E così spesso, e questa è una conversazione in evoluzione per ogni azienda. Alcune aziende vogliono solo portare a termine il lavoro. Alcune aziende vogliono essere appariscenti al riguardo.

E in tutti quei casi in cui è importante che il cliente abbia un'esperienza davvero rivoluzionaria, o qualcosa di veramente all'avanguardia in termini di prestazioni, o ha bisogno di qualcosa che sia considerevolmente più coinvolgente nella competizione, allora tutte queste cose sono molto, molto più facili da fare su Headless. E quindi la conversazione nella mia mente, o almeno l'angolazione da cui tendiamo a partire, è solo: è questo, devi farlo o è questo, devi farlo e impressionare molto le persone con esso.

Perché ovviamente WordPress lo fa da molto tempo, ed è un posto solido per costruire un sito, ma fondamentalmente, quanto "appariscente appariscente" vuoi? E se vuoi molto, allora Headless è davvero un ottimo modo per farlo

HASHIM WARREN: È fantastico. Jimmy, voglio parlare del personale in termini di agenzia. Quando pensi ai progetti Headless, vuoi sviluppatori WordPress che hanno adottato JavaScript e, diciamo, qualcosa come React? O preferiresti avere più di uno sviluppatore JavaScript che non usa nemmeno WordPress? Come pensi al personale quando si tratta di progetti Headless WordPress?

JAMES SQUIRES: Sì, è una buona domanda. La nostra agenzia, cerchiamo React come una sorta di base di base, quindi ovviamente JavaScript ed esperienza nel framework React. È una specie di nostro obbligo, a tutti i livelli, davvero. WordPress è– lo trattiamo come un "bello da avere". Questo è qualcosa, specialmente nello spazio senza testa, che possiamo addestrare in tempi relativamente brevi.

Voglio dire, in generale, con Headless trascorri il tuo tempo in WordPress sviluppando tipi di post personalizzati e disponendo semplicemente il framework dei componenti dal punto di vista del back-end, ma non stai toccando molto l'eredità, tipo di aspetti basati sul tema in una normale architettura Headless. Quindi abbiamo scoperto che non abbiamo davvero bisogno di quell'esperienza fondamentale di WordPress.

Certo, abbiamo bisogno di alcuni giocatori nel team che lo abbiano per certi aspetti, ma in generale, abbiamo avuto molto successo nel coinvolgere, diciamo, un ingegnere di React, che non ha mai toccato WordPress prima. Mostrando loro come apportare modifiche ai campi e il gioco è fatto. Capiscono già GraphQL, che è una competenza fondamentale che devi conoscere per entrare nelle architetture Headless.

Ma oltre a ciò, la conoscenza di WordPress può essere piuttosto superficiale e puoi coinvolgere qualcuno ed essere molto produttivo su un progetto. Questa è la bellezza dei componenti React: qualsiasi sviluppatore React può entrare nel bel mezzo di un progetto, guardare la mia cartella dei componenti e gliene assegniamo uno, e sono pronti per le gare purché abbiano già la struttura dei dati impostata.

HASHIM WARREN: Anche questo è davvero interessante, in termini di capacità di separare il lavoro. Lavori su questo componente e puoi lavorarci separatamente dal progetto. Questo è davvero un ottimo esempio.

Jonathan, come ci pensi quando si tratta di progetti Headless WordPress? Preferiresti avere uno sviluppatore WordPress le cui competenze, chi aggiunge React a quello, o qualsiasi framework JavaScript alla cintura? O uno sviluppatore JavaScript che esegue l'upscaling su WordPress, come ne pensi?

JONATHAN JETER: Quindi, come ha detto Jimmy, abbiamo bisogno di entrambi, ma ora cercheremo di più da React, View, sviluppatori JavaScript front-end. Bene, ora tutti si definiscono Full Stack, ma gli sviluppatori JavaScript che saranno in grado di entrare. E ho avuto sviluppatori che sono entrati e hanno detto, oh, non lavorerò in WordPress, come se non fosse qualcosa Voglio fare. E una volta entrati, stiamo facendo un progetto Headless, oh, non è poi così male.

Perché non hanno a che fare con tutto il lavoro per PHP e tutto il resto. Ma allo stesso tempo, abbiamo effettivamente spostato alcune delle nostre persone DevOps per gestire il backend WordPress, quindi non abbiamo necessariamente bisogno di uno sviluppatore backend per farlo, quindi funziona davvero bene. Andare avanti.

JAMES SQUIRES: Stavo per aggiungere a questo, almeno dalla nostra esperienza, il numero di ingegneri che puoi inserire in un progetto Headless ed essere produttivo tende ad essere molto più alto. Ad esempio, abbiamo appena lanciato un Headless basato su SvelteKit, penso sia il primo su Atlas, la scorsa settimana. Non consiglio ancora SvelteKit ai clienti, ma ci piace parecchio.

Ma avevamo un eccesso di otto ingegneri contemporaneamente che lavoravano tutti sui componenti e, con lo sviluppo basato su temi, tendiamo a faticare di più per ottenere molti ingegneri ed essere produttivi. Solo perché le cose sono un po' più monolitiche, in termini di quante cose puoi toccare contemporaneamente. Sono sicuro che sia possibile e puoi coordinarlo, ma troviamo che è molto più semplice sulle architetture Headless.

HASHIM WARREN: A proposito, è uno spettacolo bellissimo. Ho visto il lancio. È un bellissimo sito.

JAMES SQUIRES: Grazie.

JONATHAN JETER: Anche l'altra cosa che direi è che so che stiamo parlando solo di WordPress, giusto, ma ci occupiamo anche di progetti che non sono WordPress, giusto. Quindi quegli sviluppatori JavaScript possono lavorare su più sistemi di back-end, al contrario di se assumo uno sviluppatore .net, funzionano solo, per la maggior parte, funzionano solo in .net, giusto.

Quindi abbiamo le persone che si assicurano che le API funzionino, aggregando i dati, mettendo insieme tutta quella roba, giusto. E poi abbiamo i front-end che possono lavorare su uno qualsiasi di quei progetti, invece di essere specifici per una lingua specifica.

TAYO ONABULE: E penso che ci siano alcune cose qui che stiamo tutti menzionando. Penso, diciamo così com'è, come React, uno– Nel nostro caso, tendiamo comunque a restare con React. Abbiamo alcuni sviluppatori View, ma tendiamo a rimanere con React. Ma tutti questi framework front-end sono stati progettati specificamente pensando al tipo di sviluppatore e al processo. Sono progettati: immagino che il signor Facebook a un certo punto abbia detto, assicuriamoci che sia il più efficiente possibile per il nostro team.

E quindi, questo è il fulcro di ciò che è React, e sarà più o meno lo stesso per View e Angular. In termini di lato WordPress, ancora una volta, chiamalo così com'è. In sostanza, potresti cavartela solo sapendo come navigare nel backend di WordPress e utilizzando ACF. E altrimenti non ho alcuna conoscenza di WordPress e riesco comunque a creare un sito WordPress Headless.

E quindi il requisito sul lato WordPress, a meno che tu non stia cercando di fare cose che iniziano a complicarsi, potresti tecnicamente costruire un sito WordPress senza testa con fondamentalmente la conoscenza di dove si trova il file .php delle funzioni e nient'altro. Puoi cavartela. E penso che la bellezza di questo sia, come ha detto Jonathan, ancora una volta, quegli sviluppatori JavaScript saranno utili in tutti i tuoi progetti. E penso che sia abbastanza sicuro dire che per il prossimo futuro il web sarà incentrato su JavaScript, e quindi questo è un talento molto utile.

Fino a che punto l'ultimo passaggio, è probabile che ci voglia un po' di tempo. Quindi, onestamente, non è davvero un grande impegno in un certo senso. È uno che ha senso che immagino la maggior parte dei casi.

HASHIM WARREN: Voglio solo sostenere la tua storia perché in una vita precedente ho dovuto formare due sviluppatori React sul nostro nuovo sito WordPress. Ed era un sito WordPress senza testa. Ed era solo un pomeriggio. Ho mostrato loro ACF, erano davvero entusiasti, hanno realizzato i modelli di dati ed erano partiti. E persino uno degli sviluppatori ha effettivamente collegato l'editor classico e lo ha fatto in modo che io possa controllare alcuni componenti sul front-end.

Questo è prima di Gutenberg, quindi usavamo campi ripetitori e ACF e controllavamo alcuni dei componenti sul front-end. È stato stupefacente. Ma i due sviluppatori di React l'hanno capito subito. Ci è voluto solo il pomeriggio e sono partiti per le gare.

TAYO ONABULE: Questo è il fatto che con questo tipo di sviluppatori front-end, sono abbastanza abituati a collegarsi ai back-end per i loro dati e ad avere una struttura dati a cui attenersi. Questo è un componente comune del loro flusso di lavoro, quindi WordPress non fa molte probabilità.

JONATHAN JETER: Con la prevalenza di… scusate, la prevalenza di SaaS, le applicazioni ora sono disponibili ovunque, cose che facevi in ​​WordPress, che si tratti di eCommerce, sia che si tratti di integrazione con il CRM, tutto quel genere di cose. Ora non è più finito, non deve più essere fatto su WordPress. Non è necessario installare un plug-in Marketo o un plug-in Salesforce o qualcosa per provare a connetterli, giusto.

Ora stai facendo tu stesso quelle connessioni, il che consente un'esperienza migliore, un'esperienza personalizzata. Ciò consente velocità, sicurezza, tutte queste cose, invece di cercare di coinvolgere uno sviluppatore PHP per capire come far funzionare queste cose all'interno di WordPress.

HASHIM WARREN: Fantastico. Stephen, mi piacerebbe sentire la tua opinione sull'ecosistema, l'ecosistema JavaScript. So che gli sviluppatori di WordPress sono abituati a un ecosistema davvero fantastico e robusto, in termini di plugin, anche di comunità. Puoi parlare di come si confronta forse con l'ecosistema nel mondo JavaScript? Sia in termini di tecnologia che persino di comunità.

STEPHEN BROOKS: Sì, quindi con WordPress, ha il più grande mercato di plug-in per la costruzione di monoliti tradizionali. Ma tornando al punto di Jonathan appena un secondo fa, sfruttando NPM per tutte le funzionalità di cui hai bisogno dal front-end, è equivalente, se non maggiore, del marketplace di WordPress. Perché non solo hai tutti quei pacchetti NPM disponibili. Ci sono anche numerosi STK che puoi anche inserire, per creare davvero e rapidamente tutta l'integrazione dei dati di cui hai bisogno.

Quindi direi quasi che è maggiore di circa il 20%. Basta lanciare un numero arbitrario là fuori, ma è molto più veloce per le persone muoversi. E molte delle cose di NPM sono sul punto. Inoltre, non devi preoccuparti della versione principale di WP e delle mancate corrispondenze della versione del plug-in che possono verificarsi. Una volta appuntate le versioni nel manifest del pacchetto, intendo dire che hai finito. Non devi più preoccuparti di aggiornarli se non vuoi o qualcosa del genere.

Quindi, ancora una volta, torna a quello che dicono tutti, la velocità e la flessibilità sono fondamentali ogni volta che si utilizza la soluzione Headless rispetto all'approccio tradizionale di WordPress.

JAMES SQUIRES: Non per gettare ombra sulle aziende che stanno facendo un sacco di soldi con i loro plugin di WordPress, ma questa è un'altra area in cui tendi in un'architettura senza testa ad avere meno costi di licenza, dove in un tipico tema basato, c'è alcuni plugin davvero fantastici là fuori che ci ritroviamo sempre a inserire proposte da acquistare e utilizzare. Per la maggior parte, tutto in NPM è software open source gratuito.

Ce ne sono sicuramente alcuni a cui potrebbe essere associato un modello di servizio. Ma in generale, puoi trovare la soluzione più popolare ed è la licenza open source. Quindi è facile muoversi rapidamente in questo modo e non rallentarlo con l'approvazione dei clienti sui costi di licenza e cose del genere.

HASHIM WARREN: Jimmy, ho un altro esempio che è così. Quindi stavo costruendo un sito web di Gatsby e vi stavo aggiungendo Google Analytics. Gatsby ha un ecosistema di plug-in, tutti i plug-in sono open source. I loro pacchetti sono su NPM, sono facili da installare. Quindi sto aggiungendo Google Analytics e aveva tutte queste opzioni che, con il più popolare plug-in di Google Analytics per WordPress, alcune di queste opzioni vanno nella versione premium. Quindi ero molto eccitato come qualcuno che è felice di pagare per questo plug-in di WordPress per avere la stessa funzionalità con questo pacchetto che era anche un plug-in di Gatsby. Sono davvero entusiasta di come questi ecosistemi si combinino.

TAYO ONABULE: Penso che sia stato molto veloce anche sull'intero argomento NPM. Penso che sia solo la cosa più piccola, e probabilmente è irrilevante, ma io per me. Preferisco di gran lunga il fatto che quando sviluppi qualcosa in React, vuoi qualcosa, lo scarichi tramite CLI. E non devi entrare in WordPress o in qualsiasi altro tipo di appiccicoso, è solo lì nel tuo spazio. Non devi lasciare lo studio, ed è tutto lì. Ed è un processo molto meno goffo che fare qualche ricerca, trovare un plug-in, installarlo, eccetera. Non sono mai stato un fan di questo.

HASHIM WARREN: Fantastico. Jonathan, voglio chiederti, abbiamo parlato dei requisiti che ti farebbero dire che è perfetto per Headless WordPress. Che tipo di progetto ti farebbe sentire che è, OK, questo dovrebbe essere un tradizionale progetto WordPress.

JONATHAN JETER: Quindi ne facciamo molti anche noi, giusto. A volte è il budget. Entrano e dicono, abbiamo così tanto. Siamo tipo, non c'è scelta, giusto. Questo è quello che stiamo facendo, giusto. E perché, allora abbiamo cose che usiamo. Quel processo e quel sistema sono già in atto. Come diceva Jimmy, abbiamo plug-in che inseriamo in ognuna di quelle proposte perché sappiamo che è molto semplice.

Quindi un tipico sito di un piccolo marchio. Tipico– Come diceva Tayo prima, non deve essere appariscente, giusto. Non c'è niente di scandalosamente creativo in questo sito, giusto. E hanno appena detto, ehi, li abbiamo già avuti prima, come se sapessimo di aver bisogno di un sito web, quindi creane uno. Giusto. E se è così, allora, sì, assolutamente, in base al tuo budget e ai requisiti, andrà bene un sito WordPress standard.

Siamo persino arrivati ​​al punto in cui utilizzando Genesis, Genesis Pro e Smart Plugin Manager e tutto quel genere di cose, abbiamo siti che costruiamo che gli sviluppatori non toccano nemmeno. Passa attraverso il processo e il processo creativo, lo studio modifica i file e fondamentalmente inserisce il contenuto. Abbiamo alcuni editor che lo provano e inseriscono il contenuto e il sito è fatto senza che uno sviluppatore lo tocchi mai Esso.

Ed è così che devi farlo, giusto, per fare soldi con quei progetti, perché con quei tipi di budget non puoi ottenere 20 ore di sviluppo sul back-end di uno di quei siti. Quindi in genere è così che decidiamo, a meno che non si tratti di un sito enorme, ma loro dicono no, no, no, non vogliamo niente di speciale. Vogliamo solo che questo sia un sito normale. L'abbiamo fatto, solo un sacco di contenuti, blog, quel genere di cose.

Dal punto di vista SEO, WordPress è ancora eccezionale. Se è quello che stanno cercando, è come se non ci interessasse come appare. Vogliamo solo la funzione. Vogliamo che sia veloce. Vogliamo avere contenuti e posizionarci bene. Un sito WordPress tradizionale funziona bene.

HASHIM WARREN: Fantastico. Stephen, puoi parlarci? 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.