DE{CODE}: Cuándo elegir Headless para clientes

Cuando un cliente tiene requisitos de rendimiento y seguridad, ¿cuándo debería una agencia elegir WordPress tradicional o WordPress sin interfaz para el trabajo? Obtenga más información en esta sesión DE{CODE}, con un panel de expertos de agencias que opinan sobre los beneficios, las limitaciones, las oportunidades y las ventajas y desventajas de quedarse sin cabeza.

Diapositivas de la sesión

Transcripción de texto completo

HASHIM WARREN: Hola, bienvenido a nuestro panel, Cuándo elegir Headless WordPress para clientes. Así que mi nombre es Hashim Warren y soy el gerente de marketing de productos de Atlas, nuestra solución para Headless WordPress. Y una de las primeras preguntas que recibí de las personas cuando están adoptando, o quieren adoptar Headless WordPress, es cuándo debo usar WordPress tradicional, todo en uno, y cuándo debo usar Headless WordPress.

Entonces, si tengo un cliente que tiene requisitos de rendimiento y seguridad, ¿qué debo pensar en términos de adoptar o elegir WordPress sin cabeza o tradicional? Y también, si elijo Headless WordPress, ¿qué debo esperar, en qué me estoy metiendo aquí? Así que hoy tenemos un excelente panel con experiencia tanto con proyectos tradicionales de WordPress como con proyectos de Headless WordPress que podrán responder algunas de las grandes preguntas que sé que muchos de ustedes tienen.

Así que hoy conmigo tenemos a Jonathan Jeter, quien es el Director de Producción Técnica en Click Here Labs. También contamos con Stephen Brooks, el Director de Tecnología de Springbox. También tenemos a James Squires, el Director de Tecnología en el espacio 150. Y también tenemos a Tayo Onabule, el Director General de Drawl.

Solo quiero traer el panel ahora mismo, para que podamos comenzar con esta conversación. Entonces, comencemos la conversación de esta manera. Solo dígame qué hizo que usted personalmente, o su agencia, se interesara en Headless WordPress en primer lugar. Y Jonathan, ¿puedes empezar con nosotros?

JONATHAN JETER : Claro. Así que hemos estado interesados ​​en trabajar en el espacio Headless por un tiempo. Y la razón principal por la que nos interesó fue porque queríamos crear proyectos más grandes que integraran datos de múltiples fuentes. Y la API de WordPress aún no estaba allí. Así que estábamos trabajando en diferentes formas de presentar la capa frontal, aún usando el contenido de WordPress. Y eso es básicamente lo que hemos estado haciendo durante unos cinco a siete años, tratando de descubrir cuál era la mejor manera de hacerlo.

Y ahora es mucho más fácil de lo que era, obviamente hay mucho más, hay una variedad de opciones en cuanto a cómo lo vas a hacer. Y así, hemos visto crecer el espacio, y estamos muy emocionados acerca de hacia dónde se dirige. Él

HASHIM WARREN: Impresionante. Y Stephen, ¿tienes una historia similar? ¿Qué hizo que usted o su agencia se interesaran en Headless WordPress?

STEPHEN BROOKS : Sí, hemos estado en el espacio Headless desde aproximadamente 2015, lidiando tradicionalmente con plataformas CMS basadas en jam. En los últimos años, ha sido un desafío tratar con algunos equipos de marketing que trabajan dentro de un sistema jam, solo por el cambio de paradigma en la entrada de contenido, en lugar de un enfoque de publicación y tipo de página.

También hemos intentado, al igual que Jonathan, aprovechar la API de WordPress. Eso es un poco engorroso, realmente no te da exactamente lo que necesitas todo el tiempo. Cada vez que WP Engine mencionaba a Atlas y hablaba sobre las tecnologías subyacentes, era un beso de chef con lo que tradicionalmente hemos hecho en el espacio de mermelada.

Así que ahora es una conversación realmente fácil con nuestros clientes, porque casi todos los especialistas en marketing tienen experiencia trabajando dentro de WordPress, pero los desarrolladores obtienen el beneficio adicional de una solución Headless. Por lo tanto, obtiene mitigación de riesgos de seguridad, así como solo algunas de las interacciones de primera línea con una capa de presentación basada en React. Así que ese ha sido nuestro verdadero motor aquí recientemente.

HASHIM WARREN: Eso es increíble. Tayo, ¿puedes contarnos tu historia y, para seguir con eso, puedes contarnos cómo convencer a los editores para que adopten Headless WordPress?

TAYO ONABULE : Sí. Quiero decir, creo que, en nuestro caso, hemos tenido una entrada un poco más reciente y un poco diferente en el espacio Headless WordPress. Uno de los principales impulsores para nosotros es uno de nuestros clientes Android Authority, que tiene un alcance bastante amplio. Más o menos en el momento actual, insinuando algo así como la marca de 20 millones de visitantes mensuales.

Y sus necesidades son bastante simples en cierto modo. Necesitan un SEO realmente bueno, como de primer nivel. Y tienen muchos competidores muy competentes a su alrededor. Entonces, sí, un SEO realmente excelente, un rendimiento realmente excelente y una experiencia de lectura realmente excelente para todos los artículos que publican.

Así que Headless fue realmente... realmente surgió para nosotros como parte de la conversación justo cuando estábamos tratando de hacer todo lo posible para encontrar una manera de hacer que sus sitios de WordPress existentes cubran todas esas necesidades. Realmente al máximo, básicamente. Y Headless, primero fue un caso en el que yo solo investigué un poco y pensé, oh, bueno, tal vez podríamos, tal vez darle una oportunidad.

Y nos metimos más y más en ello, y pasamos por el proceso de convencer al equipo. Pero a medida que avanzamos en el desarrollo completo, comenzamos a darnos cuenta de que, sí, respondía todas esas preguntas principales, como el rendimiento de SEO y una experiencia, pero también nos dio una flexibilidad completa en el futuro a medida que pasaron los años. en.

Lanzamos, creo que fue en mayo del año pasado, por lo que en realidad nos acercamos al aniversario de eso. , Pero sí, desde ese lanzamiento hemos logrado crear una gran cantidad de integraciones en el sitio. Todo lo cual habría sido considerablemente más difícil si hubiéramos estado en WordPress monolítico o todo en uno. Esa flexibilidad que te brinda es una de las... es una de las cosas que le estaba diciendo a Android Authority que tendríamos, pero no creo que me haya dado cuenta de la escala y la libertad que brinda, básicamente.

HASHIM WARREN: Eso es increíble. Entonces, hasta ahora escuchamos sobre el rendimiento de SEO, la flexibilidad para los desarrolladores, la flexibilidad en términos de qué tipo de proyecto, y también los editores que pueden seguir con un CMS que conocen. Jimmy, ¿su experiencia coincide con algo de eso, o tiene algo que agregar en términos de lo que hizo que usted o su agencia se sintieran atraídos por Headless WordPress?

JAMES SQUIRES: Sí, creo que muchas de esas cosas que compartimos también son comunes. Lo único que probablemente agregaría que tal vez parezca un poco egoísta al principio, pero llegaré allí y explicaré por qué es algo bueno. Pero realmente para nosotros, fue realmente impulsado por la satisfacción del desarrollador.

Venimos principalmente de un marco de trabajo basado en React y React, como si estuviéramos entrando en WordPress. Y nuestros clientes exigían WordPress cada vez más, pero nuestros ingenieros realmente no están tan satisfechos con el desarrollo basado en temas en su mayor parte. Todavía lo hacemos cuando todavía hay aplicaciones en las que tiene mucho sentido, pero si sus desarrolladores están satisfechos con el producto y lo que están creando, creo que el resultado es que a menudo obtiene una experiencia estelar para que haya es un beneficio real para nuestros clientes, a pesar de que nuestro salto en realidad se centró en algo que nuestros ingenieros querían hacer.

HASHIM WARREN: Eso es increíble. Una de las cosas que muchas personas que están viendo esto habrán escuchado en las conferencias, la diferencia entre el desarrollo basado en temas para WordPress y el desarrollo basado en componentes. ¿Alguien puede hablar de eso? ¿Los beneficios de adoptar un enfoque basado en componentes al crear sitios web?

TAYO ONABULE: Sí, realmente me gustaría entrar en eso, en realidad. Del mismo modo, estoy seguro de que todos tenemos ejemplos de esto, pero creo que una de las cosas más satisfactorias que suceden cuando trabajas con bibliotecas de JavaScript, como React, en nuestra experiencia de todos modos, es sí, como dices, acceso a este tipo de estilo de construcción basado en componentes.

Y significa que, por una parte, puede dividir el diseño de un sitio completo en estos componentes que son mucho más flexibles. Entonces, digamos como ejemplo, es posible que tenga un bloque en una página que tenga dos estilos diferentes. Uno, donde la imagen está en el lado izquierdo y el texto está en el lado derecho, digamos. Solo como una especie de ejemplo simple. Y React, ese es un caso en el que tienes un bloque con un modificador, esencialmente, solo para decir, cambiar el orden del texto y la imagen.

Cuando estamos hablando de monolítico, esencialmente solo dices, sí, tal vez comienzas con la misma base, pero muy rápidamente tienes que separar los dos, y ahora tienes dos cosas separadas. Y los cambios, hasta cierto punto, tienen que distribuirse entre dos cosas separadas. Y es ese tipo de concepto lo que significa que a medida que se adentra en usos cada vez más grandes para los front-end sin cabeza, esa flexibilidad y consistencia que puede tener en todo un sitio, en todos los usos de un componente en particular, significa que el desarrollo , como dijo James anteriormente, es mucho más satisfactorio para los desarrolladores.

Es una experiencia considerablemente más agradable. Realmente se puede decir que React ha sido diseñado para maximizar el rendimiento de los desarrolladores, y es que, una vez más, como dice James, todo eso pasa al cliente. Porque creo que puedes darte cuenta cuando algo se ha hecho con amor y disfrute, como que siempre resulta en un mejor resultado.

STEPHEN BROOKS: Sí, no solo eso, Tayo. Pero también tiene otros grandes beneficios. Me refiero a que realmente le dio en la cabeza por la pieza de satisfacción del desarrollador, pero si echa un vistazo al desarrollo tradicional basado en plantillas, en lugar de un desarrollo basado en componentes, pruebas unitarias, correcto. Es realmente difícil implementar cualquier tipo de prueba unitaria dentro de un enfoque basado en temas. Con un componente, boom, está ahí para usted.

Pero quiero agregar un punto a eso, pero no es necesariamente para los desarrolladores, es más para los dueños de negocios. Por lo general, con un enfoque basado en componentes, su nivel de esfuerzo disminuye significativamente en comparación con una página de tema dada, porque sus componentes, los reutilizará en todas partes, ¿verdad? Y no requiere un tiempo adicional de tecleo, tipeo, para ir y agregar ese bloque adicional dondequiera que vaya. Solo lo construyes una vez. Cada vez que lo consumes, hidratas tu construcción. Boom, ya terminaste. Es tan hermoso, tan rápido. Es maravilloso.

JONATHAN JETER: Y tuvimos que capacitar a nuestro personal creativo, correcto, porque están tan acostumbrados a que les guste, OK, este sitio tiene 5 plantillas, o este es lo que sea. Estamos como, no, no te alejes de eso, ¿verdad? Y así terminamos llamándolo. Simplemente diseñe la página del fregadero de la cocina, a la derecha, una página con todo, a la derecha, y la construiremos a partir de ahí. Entonces, sí, ha facilitado mucho el desarrollo, pero hemos tenido que capacitar al personal en todos los ámbitos para asegurarnos de que comprendan lo que estamos haciendo y cómo lo estamos construyendo.

JAMES SQUIRES: Sí, incluso en operaciones. Quiero decir, ha cambiado la forma en que se moldean nuestras propuestas para los clientes cuando estamos haciendo esto. Hablamos de cantidades de bloques y de cómo los estamos construyendo, a diferencia de las plantillas. Y ese es un cambio de paradigma, creo, para algunos, especialmente en el lado del marketing, para pensar: tienes páginas interminables de diferentes tipos de bloques. Son realmente estos bloques y componentes centrales, y lo que estamos construyendo y analizando.

TAYO ONABULE: Y solo un último detalle sobre eso. Y creo que la mención de las propuestas es un buen punto, porque el proceso Headless cambia enormemente cualquier estimación que pueda tener sobre lo que va a tomar una función o un nuevo diseño de página. El hecho es que disminuye muy consistentemente con el tiempo. Cuanto más amplia sea su biblioteca de componentes, menos se necesita para agregar un estilo adicional o algo así, modificar un estilo en todo el sitio, agregar un nuevo diseño de página. Todas esas cosas se vuelven cada vez más fáciles.

Y creo que eso es gratificante para todos, para ser honesto.

HASHIM WARREN: Eso es muy interesante. No es solo Headless versus un sitio todo en uno, es desarrollo basado en plantillas versus basado en componentes. Y parece que toca la cotización, el trabajo del cliente y la aprobación del cliente, las pruebas y el trabajo de control de calidad, el trabajo de desarrollo y el trabajo de diseño. Y parece que hay un cambio. Y parece que hay un cambio positivo. Hay algo-

Entonces, si tiene un cliente, ingrese y diga, tengo requisitos xyz. ¿Qué conjunto de requisitos escucharía que le haría decir que esto es perfecto para un proyecto sin cabeza? Y Stephen, ¿puedes empezar con nosotros?

STEPHEN BROOKS: Sí, seguro. Entonces, lo primero que miro personalmente es la huella de seguridad que necesita la organización, ¿verdad? ¿Es este un sitio web interno o un sitio web externo? Después de eso, comenzamos a analizar, oye, ¿este CMS impulsará múltiples elementos, entrega omnicanal? Si esas dos primeras casillas están marcadas, boom, es una construcción automática sin cabeza.

Si solo se marca uno de ellos, entonces debemos hablar un poco más con nuestro cliente para asegurarnos de que esté en línea con su huella operativa. Y quiero decir que el 95 % de las conversaciones que he tenido en los últimos ocho meses han sido geniales. A todo el mundo le gusta. Es un cambio de paradigma real de todo lo demás. Así que sí.

HASHIM WARREN: No, eso es asombroso. Y Jonathan, ¿puedes hablar un poco de eso? ¿Qué conjunto de requisitos te haría sentir como, OK, esto debería ser un proyecto sin cabeza? Y también, ¿qué compensaciones le explicaría a un cliente sobre la adopción de Headless?

JONATHAN JETER: Claro, uno de los principales, más o menos al punto anterior, es ¿cuántas fuentes de datos está utilizando para agregar el contenido del sitio? ¿Y el cliente quiere usar esto como el repositorio de contenido central, a diferencia de esta y las otras ocho fuentes que tienen para su aplicación móvil o para sus medios, o para cualquier otra cosa, verdad?

Así que tenemos esa conversación. Si están como, oh sí, estamos todos dentro. Y esa es una elección obvia. Además, como agencia de publicidad, tenemos estos tipos creativos que siempre están diseñando estas cosas realmente locas, ¿verdad? Entonces, si sabemos de antemano quién es el creativo, a veces eso genera una conversación, sabemos que esto será más fácil de desarrollar como una aplicación React que tratar de personalizar ese tema. en WordPress.

Pero las compensaciones. Uno es el precio. Es más caro, es mantenimiento, verdad. Así que ahora no solo está manteniendo WordPress, correcto, está manteniendo dos pilas diferentes, dos aplicaciones diferentes. Es por eso que tomamos ese camino y usamos todo AWS y Gatsby, y todas estas cosas para hacerlo de antemano. Y así, estábamos todos adentro cuando apareció Atlas. Pensamos, oh sí, si podemos hacer todo esto en un solo lugar.

Porque durante años, hemos estado hablando con nuestro motor WP, donde yo estaba como, ustedes necesitan hacer esto porque lo estamos haciendo en otro lugar, ¿verdad? Así que pongámoslo todo junto. Así que estábamos emocionados por eso. Muy, muy contento con el proceso de construcción de sitios en Atlas. Pero la compensación es básicamente el mantenimiento, que desaparece con Atlas. El costo para el cliente, en lo que respecta al alojamiento, a diferencia de un sitio estándar de WordPress.

Pero a veces, como dije antes, el costo de desarrollar el sitio disminuye, el costo de mantener el sitio disminuye. Así que es un intercambio.

JAMES SQUIRES: Creo que otra cosa realmente importante que consideramos al debatir si es apropiado para un enfoque basado en temas o Headless, es ¿cómo se ve la transferencia después de la creación de un sitio? ¿El cliente espera que tenga recursos internos que se encarguen de esto? ¿O están buscando un socio de agencia a largo plazo en quien confiar?

Y esa es una decisión realmente crítica, porque si tienes un equipo que no está familiarizado, por ejemplo, con React, Gatsby o Next, cualquiera que sea la pila de Headless, entonces podría ser una gran sorpresa si no están familiarizados con el Arquitectura sin cabeza, y cómo se va a mantener. Entonces, eso es algo realmente importante, puede parecer obvio, pero solo para ser explícitos sobre, OK, una vez que esto se inicie, y estemos en modo de mantenimiento y transferencias, ¿cuál es el plan allí?

HASHIM WARREN: Impresionante.

TAYO ONABULE: Creo que la otra cosa que es, creo que Jonathan lo mencionó tal vez, es el hecho de que, y esto es en gran parte en lo que nos enfocamos como agencia, lo que permite Headless es principalmente una experiencia cosa. En términos de con qué interactúan tus usuarios. Y muchas veces, y esta es una conversación cambiante para todas las empresas. Algunas empresas solo quieren hacer el trabajo. Algunas empresas quieren ser llamativas al respecto.

Y en todos aquellos casos en los que es importante para el cliente tener una experiencia realmente innovadora, o algo realmente innovador en términos de rendimiento, o necesitan algo que sea considerablemente más atractivo en la competencia, entonces todas esas cosas son mucho, mucho más fáciles. hacer en Headless. Entonces, la conversación en mi mente, o al menos el ángulo desde el que tendemos a comenzar, es solo: es esto, debes hacerlo o es esto, debes hacerlo e impresionar mucho a la gente con eso.

Porque, obviamente, WordPress lo ha estado haciendo durante mucho tiempo, y es un lugar sólido para construir un sitio, pero básicamente, ¿cuánto "llamativo llamativo" quieres? Y si quieres mucho, entonces Headless es una excelente manera de

HASHIM WARREN: Eso es increíble. Jimmy, quiero hablar sobre la dotación de personal en términos de una agencia. Cuando piensas en proyectos Headless, ¿quieres desarrolladores de WordPress que hayan adoptado JavaScript y, digamos, algo como React? ¿O preferirías tener más de un desarrollador de JavaScript que ni siquiera usa WordPress? ¿Cómo piensas sobre la dotación de personal cuando se trata de proyectos Headless WordPress?

JAMES SQUIRES: Sí, es una buena pregunta. Nuestra agencia, buscamos React como una especie de línea de base central, así que obviamente JavaScript y experiencia en el marco de React. Ese es nuestro mandatorio, en todos los niveles, de verdad. WordPress es… lo tratamos como algo “agradable de tener”. Eso es algo, especialmente en el espacio Headless, que podemos entrenar con relativa rapidez.

Quiero decir, en términos generales, con Headless pasas tu tiempo en WordPress desarrollando tipos de publicaciones personalizadas y simplemente diseñando el marco de componentes desde un punto de vista de back-end, pero no estás tocando muchos de los aspectos heredados, basados ​​en temas. en una arquitectura normal, Headless. Entonces descubrimos que realmente no necesitamos esa experiencia de WordPress realmente central.

Por supuesto, necesitamos algunos jugadores en el equipo que tengan eso para ciertos aspectos, pero en general, hemos tenido mucho éxito al incorporar, por ejemplo, un ingeniero de React, que nunca antes había tocado WordPress. Mostrándoles cómo hacer cambios en los campos, y están listos y funcionando. Ya entienden GraphQL, que es una competencia central con la que debe estar familiarizado para ingresar a las arquitecturas sin cabeza.

Pero más allá de eso, el conocimiento de WordPress puede ser bastante superficial, y puedes involucrar a alguien y ser muy productivo en un proyecto. Esa es la belleza de los componentes de React: cualquier desarrollador de React puede saltar a la mitad de un proyecto, mirar mi carpeta de componentes y les asignamos uno, y están listos para las carreras siempre que tengan su estructura de datos ya configurada.

HASHIM WARREN: Eso también es muy interesante en términos de poder separar el trabajo. Usted trabaja en este componente y puede hacerlo por separado del proyecto. Ese es un gran ejemplo.

Jonathan, ¿cómo piensas sobre esto cuando se trata de proyectos Headless WordPress? ¿Preferiría tener un desarrollador de WordPress cuyas habilidades, que agregue React a eso, o cualquier marco de JavaScript en su cinturón? O un desarrollador de JavaScript que escala en WordPress, ¿qué le parece?

JONATHAN JETER: Entonces, como dijo Jimmy, necesitamos ambos, pero ahora vamos a buscar más de React, View, los desarrolladores de JavaScript de front-end. Bueno, ahora todos se hacen llamar Full Stack, pero los desarrolladores de JavaScript que van a poder intervenir. Y he tenido desarrolladores que vienen y dicen, oh, no voy a trabajar en WordPress, como si eso no fuera algo Quiero hacer. Y una vez que nos metemos en eso, estamos haciendo un proyecto sin cabeza, oh, no es tan malo.

Porque no están lidiando con todo el trabajo de PHP y todo eso. Pero al mismo tiempo, en realidad hemos movido a algunas de nuestras personas de DevOps para que manejen el backend de WordPress, por lo que no necesariamente necesitamos un desarrollador backend para hacerlo, por lo que funciona muy bien. Adelante.

JAMES SQUIRES: Iba a agregar que, al menos según nuestra experiencia, la cantidad de ingenieros que puede ingresar en un proyecto sin cabeza y ser productivo tiende a ser mucho mayor. Por ejemplo, acabamos de lanzar un Headless basado en SvelteKit, creo que es el primero en Atlas, la semana pasada. Todavía no recomiendo SvelteKit a los clientes, pero nos gusta bastante.

Pero teníamos un exceso de ocho ingenieros simultáneamente, todos trabajando en componentes, y con el desarrollo basado en temas, tendemos a tener más dificultades para conseguir muchos ingenieros y ser productivos. Solo porque las cosas son un poco más monolíticas, en términos de cuántas cosas puedes tocar a la vez. Estoy seguro de que es posible y puede coordinarlo, pero creemos que es mucho más fácil en arquitecturas sin cabeza.

HASHIM WARREN: Por cierto, es una hermosa vista. Vi el lanzamiento. Es un sitio hermoso.

JAMES SQUIRES: Gracias.

JONATHAN JETER: La otra cosa que diría, también, es que sé que solo estamos hablando de WordPress, cierto, pero también tratamos con proyectos que no son WordPress, cierto. Entonces, esos desarrolladores de JavaScript pueden trabajar en múltiples sistemas back-end, a diferencia de si contrato a un desarrollador de .net, solo funcionan, en su mayor parte, solo funcionan en .net, ¿verdad?

Así que tenemos a las personas que se aseguran de que las API funcionen, agregando los datos, reuniendo todo eso, ¿verdad? Y luego tenemos los front-end que pueden trabajar en cualquiera de esos proyectos, en lugar de ser específicos de un idioma específico.

TAYO ONABULE: Y creo que hay algunas cosas aquí que todos estamos mencionando. Creo, digámoslo como es, como React, uno– En nuestro caso, tendemos a seguir con React de todos modos. Tenemos algunos desarrolladores de View, pero tendemos a quedarnos con React. Pero todos estos marcos front-end se han diseñado específicamente teniendo en cuenta el tipo de desarrollador y el proceso. Están diseñados: me imagino que el Sr. Facebook en algún momento dijo, asegurémonos de que esto sea lo más eficiente posible para nuestro equipo.

Y entonces, eso es fundamental para lo que es React, y será lo mismo para View y Angular. En términos del lado de WordPress, una vez más, llámalo como es. Esencialmente, podría arreglárselas con solo saber cómo navegar por el backend de WordPress y usar ACF. Y de lo contrario, no tiene conocimiento de WordPress y aún así logra construir un sitio de WordPress Headless.

Y entonces, el requisito en el lado de WordPress, a menos que esté tratando de hacer cosas que comienzan a complicarse, técnicamente podría construir un sitio de WordPress sin cabeza con básicamente conocimiento de dónde está el archivo de funciones .php y nada más. Puedes arreglártelas. Y creo que la belleza de esto es, como dijo Jonathan, una vez más, esos desarrolladores de JavaScript serán útiles en todos sus proyectos. Y creo que es bastante seguro decir que, en el futuro previsible, la web se centrará en JavaScript, por lo que es un talento muy útil.

Qué tan lejos en la línea ese último cambio, es probable que pase un tiempo. Entonces, honestamente, no es realmente un gran compromiso de alguna manera. Es uno que tiene sentido que imagino en la mayoría de los casos.

HASHIM WARREN: Solo quiero respaldar su historia porque en una vida anterior, tuve que capacitar a dos desarrolladores de React en nuestro nuevo sitio de WordPress. Y era un sitio de WordPress sin cabeza. Y fue solo una tarde. Les mostré ACF, estaban muy emocionados, hicieron los modelos de datos y se fueron. E incluso uno de los desarrolladores realmente conectó el editor clásico y lo hizo para que yo pueda controlar algunos componentes en la interfaz.

Esto es antes de Gutenberg, por lo que usábamos campos repetidores y ACF, y controlábamos algunos de los componentes en el front-end. Fue increíble. Pero los dos desarrolladores de React lo entendieron de inmediato. Solo les tomó la tarde y se fueron a las carreras.

TAYO ONABULE: El problema es que con este tipo de desarrolladores front-end, están bastante acostumbrados a conectarse a back-ends para obtener sus datos y tener una estructura de datos a la que adherirse. Ese es un componente común de su flujo de trabajo, por lo que WordPress no tiene muchas probabilidades.

JONATHAN JETER: Con el predominio de… lo siento, el predominio de SaaS, las aplicaciones están disponibles en todas partes ahora, cosas que solías hacer en WordPress, ya sea comercio electrónico, ya sea integración con CRM, todo ese tipo de cosas. Ahora eso no está hecho, ya no tiene que hacerse en WordPress. No tiene que instalar un complemento de Marketo o un complemento de Salesforce, o algo así para intentar conectarlos, ¿verdad?

Ahora estás haciendo esas conexiones tú mismo, lo que permite una mejor experiencia, una experiencia personalizada. Eso permite velocidad, seguridad, todas esas cosas, en lugar de tratar de conseguir un desarrollador de PHP para descubrir cómo hacer que estas cosas funcionen dentro de WordPress.

HASHIM WARREN: Impresionante. Stephen, me encantaría saber de usted sobre el ecosistema, el ecosistema de JavaScript. Sé que los desarrolladores de WordPress están acostumbrados a un ecosistema realmente impresionante y robusto, en términos de complementos, también a la comunidad. ¿Puedes hablar sobre cómo se compara con quizás el ecosistema en el mundo de JavaScript? Tanto en términos de tecnología e incluso de comunidad.

STEPHEN BROOKS: Sí, así que con WordPress, tiene el mercado más grande de complementos para la construcción monolítica tradicional. Pero volviendo al punto de Jonathan hace un segundo, aprovechar NPM para toda la funcionalidad que necesita desde el front-end, es equivalente, si no mayor, que el mercado de WordPress. Porque no solo tienes todos esos paquetes de NPM que hay disponibles. También hay numerosos STK que también puede incorporar para crear realmente y rápidamente toda la integración de datos que necesita.

Así que casi diría que es mayor en aproximadamente un 20%. Simplemente lanzando un número arbitrario, pero es mucho más rápido para la gente moverse. Y muchas de las cosas de NPM están en punto. Tampoco tiene que preocuparse por la versión principal de WP y las discrepancias de la versión del complemento que pueden ocurrir. Una vez que ancle sus versiones en el manifiesto de su paquete, quiero decir que ha terminado. Realmente ya no tienes que preocuparte por actualizarlos si no quieres o algo por el estilo.

Entonces, nuevamente, se remonta a lo que todos dicen, la velocidad y la flexibilidad son primordiales cuando se usa la solución Headless en lugar del enfoque tradicional de WordPress.

JAMES SQUIRES: No arrojar ninguna sombra a las empresas que están ganando mucho dinero con sus complementos de WordPress, pero esa es otra área, ya que en una arquitectura sin cabeza tiende a tener menos costos de licencia, donde en un típico basado en temas, hay algunos complementos realmente geniales que siempre encontramos en propuestas para comprar y utilizar. En su mayor parte, todo en NPM es software gratuito de código abierto.

Ciertamente hay algunos que pueden tener un modelo de servicio asociado con ellos. Pero, en términos generales, puede encontrar la solución más popular y es una licencia de código abierto. Por lo tanto, es fácil moverse rápidamente de esa manera y no disminuir la velocidad con las aprobaciones de los clientes sobre los costos de licencias y cosas por el estilo.

HASHIM WARREN: Jimmy, tengo otro ejemplo que es así. Así que estaba creando un sitio web de Gatsby y le estaba agregando Google Analytics. Gatsby tiene un ecosistema de complementos, todos los complementos son de código abierto. Sus paquetes están en NPM, son fáciles de instalar. Así que estoy agregando Google Analytics, y tenía todas estas opciones que, con el complemento de Google Analytics más popular para WordPress, algunas de esas opciones van a la versión premium. Así que estaba muy emocionado como alguien que está feliz de pagar por este complemento de WordPress para tener la misma funcionalidad con este paquete que también era un complemento de Gatsby. Muy entusiasmado con la forma en que esos ecosistemas encajan.

TAYO ONABULE: Creo que también fue muy rápido en todo el tema de NPM. Creo que es la cosa más pequeña, y probablemente sea intrascendente, pero yo para mí. Prefiero el hecho de que cuando estás desarrollando algo en React, quieres algo, lo descargas a través de CLI. Y no tienes que ir a WordPress, o cualquier tipo de pegajosidad, simplemente está ahí en tu espacio. No tienes que salir del estudio, y todo está ahí. Y es un proceso mucho menos complicado que investigar un poco, encontrar un complemento, instalarlo, etcétera. Nunca he sido fanático de eso.

HASHIM WARREN: Impresionante. Jonathan, quiero preguntarte, hablamos sobre los requisitos que te harían decir que esto es perfecto para Headless WordPress. ¿Qué tipo de proyecto te haría sentir que está bien, debería ser un proyecto tradicional de WordPress?

JONATHAN JETER: Así que también hacemos muchos de esos, ¿verdad? A veces es el presupuesto. Entran y dicen, tenemos tanto. Estamos como, no hay elección, ¿verdad? Esto es lo que estamos haciendo, ¿verdad? Y porque, entonces tenemos cosas que usamos. Ese proceso y ese sistema ya están en marcha. Como decía Jimmy, tenemos complementos que integramos en cada una de esas propuestas porque sabemos que es muy sencillo.

Entonces, un sitio típico de marca pequeña. Típico– Como Tayo decía antes, no tiene que ser llamativo, ¿verdad? No hay nada escandalosamente creativo en este sitio, ¿verdad? Y simplemente dijeron, oye, los hemos tenido antes, como si supiéramos que necesitamos un sitio web, así que haznos uno. Bien. Y si ese es el caso, entonces, sí, absolutamente, según su presupuesto y los requisitos, un sitio estándar de WordPress servirá.

Incluso llegamos al punto en que usando Genesis, Genesis Pro, Smart Plugin Manager y todo ese tipo de cosas, tenemos sitios que creamos que los desarrolladores ni siquiera tocan. Simplemente pasa por el proceso y el proceso creativo, el estudio edita los archivos, y básicamente ponen el contenido. Tenemos algunos editores que lo prueban, y ponen el contenido, y el sitio se hace sin que un desarrollador lo toque. él.

Y esa es la forma en que tienes que hacerlo, correcto, para ganar dinero con esos proyectos, porque con ese tipo de presupuestos, no puedes obtener 20 horas de desarrollo en el back-end de uno de esos sitios. Por lo general, así es como decidimos, a menos que sea un sitio enorme, pero dicen no, no, no, no queremos nada lujoso. Solo queremos que este sea un sitio regular. Hemos hecho eso, solo una gran cantidad de contenido, blogs, ese tipo de cosas.

En cuanto a SEO, WordPress sigue siendo excelente. Si eso es lo que están buscando, es como si no nos importara cómo se ve. Sólo queremos la función. Queremos que sea rápido. Queremos tener contenido y clasificar bien. Un sitio tradicional de WordPress funciona bien.

HASHIM WARREN: Impresionante. Stephen, ¿puedes hablar de eso? 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.