WordPress y Jamstack

Recientemente moderé un panel en la Jamstack Conf virtual de Netlify que incluyó al CEO de Netlify, Matt Biilman, y al fundador de Automattic, Matt Mullenweg. Todo esto se desarrolló, al menos para algunos, como un enfrentamiento entre “Jamstack y WordPress”.

Tengo muchas ideas propias sobre esto y creo que soy más útil como experto que como moderador. ¡Esta es una de mis conversaciones favoritas sobre tecnología en este momento! Así que permítanme escribir un blog.

Divulgación : tanto Automattic como Netlify son patrocinadores activos de este sitio. Tengo sitios de producción que usan ambos y, honestamente, soy fanático de ambos, lo cual es un punto general que intentaré resaltar. También estoy escribiendo y publicando esto en un sitio de WordPress.

historia

1. Richard MacManus publicó “El cofundador de WordPress Matt Mullenweg no es fanático de JAMstack” con citas de una conversación por correo electrónico entre ellos y una línea de Matt que dice: “JAMstack es una regresión para la gran mayoría de las personas que lo adoptan” .
2. Matt Biilmann publicó una respuesta “Sobre Mullenweg y Jamstack: ¿regresión o futuro?” con una sección completa titulada “El fin de la era WordPress”.
3. La gente intervino a lo largo del camino. Ohad Eder-Pressman, miembro de la junta directiva de Netlify, escribió una carta abierta. Sarah Gooding reanudó parte de la actividad en WP Tavern (que es propiedad de Matt Mullenweg). Yo también intervengo.
4. Matt Mullenweg aclaró los comentarios con algunas ideas nuevas.

El debate fue el 6 ^de octubre en Jamstack Conf Virtual 2020. No hay ningún vídeo público de ello (lo siento).

la pila

Comparar Jamstack con WordPress es un poco extraño. Lo que es comparable es el hecho de que ambos son caminos que puedes recorrer al crear un sitio web. Gran parte de esta publicación tendrá esto en cuenta y comparará los dos de esa manera. La razón por la que no son directamente comparables es porque:

• Jamstack es un descriptor vago de una filosofía arquitectónica que fomenta archivos estáticos en CDN y servicios a los que se accede mediante JavaScript para cualquier necesidad dinámica.
• WordPress es un CMS en la pila LAMP.

Esas cosas no son manzanas con manzanas.

Si nos quedamos sólo con la pila por un momento, la comparación sería entre:

• Alojamiento estático + Servicios
• LÁMPARA

Un ejemplo de Static + Services es usar Netlify para hosting (que es estático) y usar servicios para hacer cualquier cosa dinámica que necesites hacer. Tal vez utilice los propios formularios y la funcionalidad de autenticación de Netlify y Hasura para el almacenamiento de datos.

En una pila LAMP, tiene MySQL para almacenar datos, por lo que no necesita recurrir a un servicio externo allí. También tienes PHP disponible. Entonces, con ellos (además del software de código abierto), tienes lo que necesitas para la autenticación. No significa que nunca busques servicios; Simplemente lo hace con menos frecuencia ya que tiene más tecnología a su alcance desde el servidor que ya tiene.

Matt B. llamó a la pila LAMP un “monolito”. Matt M. se opuso a ese término y lo llamó “enfoque integrado”. No soy informático, pero veo que esto puede ir en cualquier dirección. Aquí está Wikipedia:

[…] una aplicación monolítica describe una aplicación de software de un solo nivel en la que la interfaz de usuario y el código de acceso a datos se combinan en un solo programa.

Definido de esa manera, sí, WordPress parece ser un monolito y, sin embargo, el artículo de Wikipedia continúa:

[…] una aplicación monolítica describe una aplicación de software diseñada sin modularidad.

Visto así, parece descalificar a WordPress como monolito. La arquitectura de ganchos y complementos de WordPress es modular. ‍♂️

Sería interesante escuchar a estos dos chicos profundizar en los matices, pero el software es el que es. Un sitio de WordPress autohospedado se ejecuta en un servidor con una pila completa de tecnología disponible. Tiene sentido pedirle a ese servidor todo lo que pueda (es decir, integrado). En un enfoque Jamstack, el servidor está separado de usted. Todo lo demás que necesitas hacer está dividido en diferentes servicios (es decir, no integrado).

El enfoque de WordPress no significa que nunca recurra a servicios externos. En ambas pilas, probablemente usarías algo como Stripe para las API de comercio electrónico. Podrías recurrir a algo como Cloudinary para un almacenamiento y servicio de medios sólidos. Incluso el servicio Jetpack de WordPress (que uso y me gusta) aporta mucha potencia a un sitio de WordPress autohospedado al comportarse como un servicio de terceros y mover cosas como el alojamiento de activos y la tecnología de búsqueda fuera de sus propios servidores al moverlos. un servidor en la nube. Ambas pilas son conglomerados de tecnologías.

Ninguna pila es más “castillo de naipes” o más propensa que la otra. A todos los sitios web se les puede aplicar esa metáfora de “sólo es tan fuerte como su eslabón más débil”. Si un complemento de WordPress incluye una versión modificada o de alguna manera se corrompe al cargarlo, puede arruinar mi sitio hasta que lo solucione. Si mis claves API dejan de ser válidas para mi base de datos sin servidor, mi sitio Jamstack podría quedar bloqueado hasta que lo solucione. Si Stripe no funciona, no venderá ningún producto en ningún tipo de sitio hasta que vuelva a funcionar.

Precios

WordPress.com tiene un plan gratuito y ese es absolutamente un lugar donde puedes crear un sitio. (Tengo varios). Pero realmente no tienes acceso al estilo de desarrollador hasta que estés en el plan de negocios a $25 por mes. El WordPress autohospedado en sí es de código abierto y gratuito, pero no encontrarás un lugar para crear un sitio de WordPress autohospedado de forma gratuita. Comienza barato y crece. Necesita alojamiento LAMP para ejecutar WordPress. A continuación se muestran algunos aviones de alojamiento bastante económicos:

• Un plan Bluehost “compartido” comienza en $3,95/mes.
• El plan más bajo de Flywheel es de $14 al mes. (Este sitio está en un plano Flywheel de nivel superior).
• Media Temple tiene hosting específico para WordPress desde $20/mes. (Este sitio estuvo en un plan de Media Temple de alto nivel durante mucho tiempo).
• El servicio Pressable de Automattic tiene un plan desde $25/mes.

Hay dinero involucrado desde el principio.

Comenzar gratis es mucho más común con Jamstack, luego incurre en costos en diferentes puntos. Al ser Jamstack más nuevo, se siente como un mercado que todavía se está descubriendo.

• Vercel es gratuito hasta que necesites miembros del equipo o funciones como sitios protegidos con contraseña. Un único sitio protegido con contraseña cuesta $150 al mes. Puede implementar la autenticación básica en cualquier servidor con Apache sin costo adicional.
• Netlify es muy similar, desbloquea funciones en planos superiores y ofrece funciones a la carta por sitio, como análisis ($9/mes) y autenticación (5000 usuarios activos cuestan $99/mes).
• AWS Amplify comienza de forma gratuita, pero como todo en AWS, su uso se mide en muchos niveles, como minutos de compilación, almacenamiento y ancho de banda. Tienen un cálculo de ejemplo de una aplicación web que tiene 10.000 usuarios activos diarios y se actualiza dos veces al mes, lo que cuesta 65,98 dólares al mes.
• Azure Static Web Apps aún no ha publicado los precios, pero es casi seguro que tendrá un nivel gratuito o un uso gratuito o algún tipo.

Todo esto es un buen recordatorio de que Netlify no es el único en el juego Jamstack. Jamstack simplemente significa alojamiento estático más servicios.

No se pueden hacer declaraciones generales como que Jamstack es más barato. Depende demasiado del uso y las necesidades del sitio. Con un uso elevado y una gran cantidad de servicios premium, Jamstack (al igual que Serverless en general) puede resultar muy caro. Jamstack dice que sus precios empresariales comienzan en $ 3,000 al mes, y si bien obtienes cosas como autenticación, formularios y manejo de medios, no obtienes un CMS ni ningún almacenamiento de datos, lo que probablemente te haga subir mucho más.

Si bien este sitio de WordPress no es empresarial, puedo decirles que requiere un servidor cercano a los $1,000 al mes, y eso supone que Cloudflare está al frente para ayudar a reducir el ancho de banda directamente al host y Jetpack maneja cosas como el alojamiento de medios. y funcionalidad de búsqueda. Mailchimp envía nuestra newsletter. Wufoo potencia nuestras formas. También tenemos complementos de pagos, como Advanced Custom Fields Pro y algunos complementos de WooCommerce. Eso no es todo. Probablemente sean unas pocas millas por mes, en total. Esto no es exclusivo de ningún enfoque integrado, pero ayuda a ilustrar que el costo de un sitio de WordPress también puede ser bastante alto. No publican precios (una táctica empresarial común), pero el propio servicio de alojamiento VIP de WordPress de Automattic seguramente comienza a mediados de las 4 cifras antes de comenzar a agregar cosas de terceros.

En pocas palabras: aquí no se está produciendo ningún cambio radical en los precios.

Actuación

El 80% del rendimiento web es una preocupación del front-end.

Esa es una historia real, pero también se basa en la base del servidor (que representa el primer 20%). El front-end más rápido del mundo no se siente veloz en absoluto si la primera solicitud del servidor demora varios segundos. Debe asegurarse de que la primera solicitud sea rápida si desea un sitio rápido.

¿Sabes qué es súper rápido? CDN global que sirve archivos estáticos. Eso es lo que desea que suceda en cualquier sitio web, independientemente de la pila. Si bien esa es la base de Jamstack (alojamiento estático respaldado por CDN), no significa que WordPress no pueda hacerlo.

Tomas un index.htmlarchivo con contenido estático, lo pones en Netlify y echará humo rápidamente. Tal vez su generador de sitio estático cree ese archivo (que, vale la pena señalar, bien podría obtener contenido de WordPress). Hay algo muy agradable en la solidez y la base firme de eso.

De forma predeterminada, WordPress no crea archivos estáticos que se puedan almacenar en caché en una CDN global. WordPress responde a solicitudes de un único origen, ejecuta PHP, que solicita cosas a la base de datos, antes de generar una respuesta y luego, finalmente, se devuelve la página. Esto puede ser bastante rápido, pero es mucho menos resistente que un archivo estático en una CDN global y es mucho más fácil abrirlo con solicitudes.

Los servidores de WordPress lo saben e intentan resolver el problema a nivel de alojamiento. Basta con mirar el enfoque de WP Engine. Sin que usted haga nada, utilizan un caché de página para que el sitio pueda esencialmente devolver un activo estático en lugar de tener que ejecutar PHP o acceder a una base de datos. También emplea todo tipo de almacenamiento en caché, incluida la asociación con Cloudflare para realizar el mejor almacenamiento en caché posible. Mientras escribo esto, mi sitio shoptalkshow.com literalmente cayó. Le escribí al anfitrión, Flywheel, para ver qué pasaba. Resulta que cuando ingresa allí para activar un sitio de prueba, presiona un interruptor equivocado y desactiva su almacenamiento en caché. El sitio no pudo soportar el tráfico y simplemente murió. Al volver a activar el interruptor de almacenamiento en caché se resuelve instantáneamente. No tenía Cloudflare frente al sitio, pero debería haberlo hecho.

Cloudflare es parte de la salsa mágica para hacer que WordPress sea rápido. Simplemente colocarlo frente a su sitio de WordPress autohospedado hará un montón de trabajo para hacerlo y confiable. Una de las piezas que faltan ha sido un excelente almacenamiento en caché del HTML en sí, del que literalmente se ocuparon este mes y que ahora también se puede almacenar en caché. Hay una especie de ironía divertida en que almacenar en caché WordPress significa almacenar en caché las aplicaciones como HTML estático y activos estáticos, y servirlas desde una CDN global, que es esencialmente lo que es Jamstack al final del día.

Matt M. mencionó que WordPress.com emplea CDN globales que se activan en ciertos niveles de tráfico. No estoy seguro de si es Cloudflare o no, pero no lo dudaría.

Con Cloudflare frente a un sitio de WordPress, veo los mismos números de primera respuesta que veo en los sitios de Netlify sin Cloudflare (porque no recomendamos usar Cloudflare frente a sitios alojados en Netlify). Son números de milisegundos de dos dígitos, lo cual es muy, muy bueno.

A partir de esa base, cualquier discusión sobre el rendimiento se vuelve específica del front-end. Las tácticas de front-end para la velocidad son las mismas sin importar cuál sea la situación del servidor, hosting o CMS en el back-end.

Seguridad

Hay muchas más historias sobre sitios de WordPress pirateados que sitios de Jamstack. ¿Pero es justo decir que WordPress es menos seguro? WordPress tiene un par de décadas de historia y tiene un par de órdenes de magnitud más sitios creados que Jamstack. Dejando a un lado la seguridad, obtendrás más historias de WordPress con esos números.

Matt M mencionó que whitehouse.gov está en WordPress, que obviamente es un sitio que necesita los niveles más altos de seguridad. No es que WordPress en sí sea un software inseguro. Es lo que haces con él. ¿Tienes contraseñas inseguras? Eso es inseguro sin importar qué plataforma estés usando. ¿El servidor en sí es inseguro a través de permisos de archivos o niveles de acceso? Eso no es exactamente culpa del software, pero es posible que usted esté en esa posición debido al software. ¿Está ejecutando la última versión de WordPress? El uso está fragmentado, en el mejor de los casos, y cuanto más antigua sea la versión, menos segura será. Complicado.

Quizás sea más interesante pensar en los vectores de seguridad. Es decir, en qué puntos es posible ser hackeado. Si tiene un archivo estático en un alojamiento estático, creo que es seguro decir que hay bastantes vectores de ataque. Pero aún así, hay algunos:

• Tu cuenta de hosting podría ser hackeada
• Tu repositorio de Git podría estar pirateado
• Tu cuenta de Cloudflare podría ser pirateada
• Su nombre de dominio podría ser robado (sucede)

Todo eso también se aplica a un sitio de WordPress, solo que hay vectores de ataque adicionales como:

• Código del lado del servidor: XSS, complementos incorrectos, ejecución remota, etc.
• Vulnerabilidades de la base de datos
• Ejecutar una versión anterior y desactualizada de WordPress
• El sistema de inicio de sesión está directamente en el sitio, por ejemplo, los malos pueden martillar/wp-login.php

Creo que es justo decir que hay más vectores de ataque en un sitio de WordPress, pero hay muchos vectores en cualquier sitio. La cuenta de alojamiento de cualquier sitio es un gran vector. Cualquier cosa que se encuentre en la cadena DNS. Cualquier servicio de terceros con inicios de sesión. Cualquier cosa con una clave API.

Experiencia personal: este sitio está en WordPress y nunca ha sido pirateado, pero no por falta de intentos. Siento que necesito pensar más en la seguridad de mis sitios de WordPress que en mis sitios que solo se crean a partir de generadores de sitios estáticos.

escalada

Ampliar cualquiera de los enfoques cuesta dinero. Este sitio de WordPress no tiene una escala masiva, pero requiere una ampliación decente de los requisitos del servidor de nivel básico. Sirvo todo el tráfico a través de Cloudflare, por lo que un pico en los últimos 30 días me indica que sirvo 5 TB de ancho de banda al mes.

En un plan Netlify Business (600 GB de tráfico por $99, luego $20 por 100 GB adicionales), los cálculos equivalen a $979. ¿Recuerdas cuando dije que este sitio requiere un servidor que cuesta alrededor de $1,000 al mes? Escribí eso antes de ejecutar estos números, así que estuve muy cerca (veme). Jamstack versus WordPress a la escala de este sitio está bastante reñido. Todos los hosts cobrarán por el ancho de banda y tendrán límites con cargas por exceso. Amplify cobra $0,15/GB por encima de un límite mensual de 15 GB. Flywheel (mi host de WordPress) cobra según un límite de visitantes mensual y, por encima de eso, es $1 por cada 1000.

La historia con el escalado de WordPress es:

• Utilice un host que pueda manejarlo y que tenga su propia estrategia de almacenamiento en caché comprobada.
• CDN todo (lo que generalmente significa poner Cloudflare delante).
• Al final vas a pagar por ello.

La historia del escalado de Jamstack es:

• El host y los servicios están diseñados a escala.
• Tienes que pensar en escalar menos en términos de ¿puede este servicio manejar esto o tengo que mudarme?
• Tienes que pensar en escalar más en términos del hecho de que cada aspecto de cada servicio tendrá precios que debes vigilar.
• Al final vas a pagar por ello.

Tuve que cambiar un poco con mi hosting de WordPress, encontrando hosts que estarían en línea con las necesidades actuales del sitio. Mover un sitio de WordPress no es trivial, pero es mucho más fácil que pasar a otro CMS. Por ejemplo, si crea un sitio Jamstack en un CMS sin cabeza que se vuelve demasiado costoso, el costo de mudarse es un trabajo mayor que cambiar de host.

Me gusta lo que Dave Rupert escribió el otro día (en una conversación de Slack) sobre comparar el rendimiento entre los dos:

Jamstack: use lo que sea para construir lo suyo, hay complementos que lo ayudarán y use lo nuestro para implementarlo en una CDN para que no se caiga.

WordPress: usa lo nuestro para construir lo tuyo, hay complementos que te ayudarán y debes usar ciertos hosts para que no se caiga.

También existen otros tipos de “escalamiento”. Pienso en algo así como número de usuarios . Eso es algo que todo tipo de servicios se utilizan para los niveles de precios, lo cual es una métrica comprensible. Pero eso es gratis en WordPress. Puede tener tantos usuarios con tantos permisos matizados como desee. Eso es solo el CMS, por lo que agregar otros servicios aún podría cobrarle una fortuna. Vercel o Netlify te cobran por cabeza por las cuentas del equipo. Contentful (un popular CMS sin cabeza) comienza en $489/mes para equipos. Incluso el nivel Team de GitHub cuesta $4 por usuario si necesitas algo que la cuenta gratuita no pueda hacer.

Dividiendo el frente y la espalda

Esta es una de las cosas más importantes que entusiasma a la gente a la hora de crear con Jamstack. Si toda la funcionalidad y el contenido de mi sitio están detrás de las API, eso libera al front-end para construir como quiera.

• ¿Quieres crear un sitio totalmente estático? Bien, acceda a esa API durante el proceso de compilación y hazlo.
• ¿Quieres crear un sitio renderizado por el cliente con React o Vue o lo que sea? Bien, acceda al lado del cliente API.
• ¿Quieres dividir por la mitad, renderizar previamente algunos, renderizar otros en el cliente y otros en el servidor? Genial, es una API, puedes utilizarla como quieras.

Esa flexibilidad es clara en las nuevas construcciones, pero la gente está igualmente entusiasmada con la flexibilidad teórica futura . Si toda la funcionalidad y el contenido están impulsados ​​por API, habrá dividido completamente el frente y la parte posterior, lo que significa que puede cambiar cualquiera de ellos en el futuro con más flexibilidad.

• Mientras su API sigue mostrando lo que espera el front-end, puede rediseñar el back-end sin molestar al front-end.
• Siempre que obtenga los datos que necesita, puede rediseñar la interfaz sin afectar la parte posterior.

Este tipo de división parece “seguro para el futuro” para sitios de cierto tamaño y escala. No puedo identificar cuáles son esos números de escala, pero están ahí.

Si alguna vez ha realizado una reestructuración importante de un sitio solo para acomodar un lado o el otro, pasar a un sistema en el que haya dividido la parte trasera y la delantera seguramente le parecerá una decisión inteligente.

Puede dividir un sitio de WordPress (llegaremos a eso en la sección “Usar ambos”), pero de forma predeterminada, WordPress es en gran medida un enfoque integrado donde la interfaz se construye a partir de temas en PHP utilizando API muy específicas de WordPress. No dividido en absoluto.

Experiencia del desarrollador

Jamstack ha hecho un buen trabajo al priorizar en gran medida la experiencia del desarrollador ( DX ). Escuché a alguien llamarlo “un óptimo local”, lo que significa que Jamstack está diseñado en torno a la experiencia del desarrollo local (y del desarrollador local).

• Se espera que trabaje localmente. Trabaja en tu propio entorno de desarrollo cómodo (local, rápido, personalizado).
• Git es un ciudadano de primera clase. Usted ingresa a su rama de producción (por ejemplo, mastero main), luego se ejecuta el proceso de compilación y se implementa su sitio. Incluso obtienes una URL de vista previa de cuál será el sitio de producción para cada solicitud de extracción, lo cual es una característica impresionantemente excelente.
• Utilice cualquier herramienta que desee. ¿Quieres preconstruir un sitio en Hugo? A por ello. ¿Aprendiste create-react-appen la escuela? Usa eso. ¿Quieres experimentar con el nuevo y genial marco de trabajo del día? Tienen en él. Hay mucha libertad para construir como quieras, aprovechando el hecho de que puedes ejecutar una compilación e implementar cualquier carpeta en tu repositorio que desees.
• Lo que no tienes que hacer también es importante. No tiene que lidiar con HTTPS, no tiene que lidiar con el almacenamiento en caché, no tiene que preocuparse por los permisos de los archivos, no tiene que configurar una CDN. Incluso los desarrolladores avanzados aprecian tener que hacer menos.

No es que WordPress no considere la experiencia del desarrollador (por ejemplo, tienen una CLI y puede hacer cosas útiles, como bloques de andamio), pero para mí el DX no es el núcleo del proyecto.

• Ejecutar WordPress localmente es complicado, ya que requiere que ejecutes una pila (X)AMP de alguna manera, lo que implica software de terceros notoriamente complicado. Gracias a Dios por Local de Flywheel. Hay alguna orientación, pero no parece una prioridad.
• ¿Qué debería ir en Git? Hasta el día de hoy, no lo sé realmente, pero ya yo he decidido por toda la /wp-contentcarpeta. Me parece extraño que no haya orientación ni mejores prácticas obvias.
• Estás totalmente solo para el despliegue. Incluso los hosts específicos de WordPress no lo logran aquí. En gran medida es simple: aquí están sus credenciales SFTP.
• Incluso si tiene un buen desarrollo local y un proceso de implementación configurado (estoy contento con el mío), eso realmente no ayuda a lidiar con el movimiento de la base de datos, por lo que también estará solo allí.

Todas estas son cosas que se pueden resolver, y la comunidad de WordPress es tan grande que encontrará mucha información al respecto, pero creo que es justo decir que WordPress no tiene DX hasta el núcleo. Es un poco del salvaje oeste incluso después de todos estos años.

De hecho, he descubierto que debido a que se deja de lado el fomento de un entorno de desarrollo local saludable, mucha gente simplemente no lo tiene en absoluto. Esto es anecdótico, pero ahora el doble de años me he encontrado involucrado en sitios de otras personas que funcionan exclusivamente en producción. Eso sería una cosa si fueran sitios muy simples con un comportamiento en gran medida predeterminado, pero esto ha sido todo lo contrario. Son muy complicados (mucho más que este sitio) e involucran inicios de sesión de usuarios públicos, membresías y permisos pagados, creadores de páginas, códigos cortos personalizados, CSS personalizado y un montón de partes móviles. Me dio un susto de muerte. No quería tocar nada. Estaban editando PHP en vivo para que todo funcionara: codificación de vaqueros, como la gente lo llama en broma. Un error de sintaxis y el sitio queda arruinado, tal vez incluso la misma página que estás viendo.

El hecho de que WordPress impulse una franja tan grande de la web sin un DX particularmente bueno es muy interesante. No existe Jamstack sin DX. Es algo totalmente centrado en los desarrolladores. Con WordPress, probablemente no haya ningún desarrollador en la mayoría de los sitios. Se instala (o simplemente se activa, en el caso de WordPress.com) y el propietario del sitio lo toma desde allí. El propietario del sitio es como un desarrollador en el sentido de que tiene mucho poder, pero quizás no escribe ningún código.

Con ese fin, diría que WordPress se centra mucho más en UX que en DX, lo cual es una gran parte de todo esto...

CMS y UX del usuario final

WordPress es un CMS muy bueno. Incluso si no te gusta, hay muchísimas personas a las que les gusta, y los números hablan por sí solos. Lo que obtienes, cuando decides crear un sitio con WordPress, es una gran ayuda para crear casi cualquier tipo de sitio que desees. Es poco probable que tengas esa situación, ¡vaya!, me arrinconé aquí con WordPress.

Eso es un gran problema. Jenn señaló esto y señaló que las personas que usan WordPress son una historia más importante que las necesidades de un desarrollador.

WordPress puede hacer un montón de cosas:

• Blog (o cualquier tipo de sitio estilo CMS basado en contenido)…
  • Con vistas previas de contenido, lo cual es posible pero complicado en Jamstack
• Tratar con usuarios/permisos...
  • en el nivel de administrador/CMS, y
  • en el nivel de cara al futuro (por ejemplo, foros, suscripciones, redes sociales, etc.)
• comercio electrónico
• Formularios de proceso
• Manejar complementos a la luna y viceversa

Jamstack también puede hacer todas estas cosas, pero ahora es Jamstack el que está en territorio del Salvaje Oeste. Cuando miras tutoriales sobre cómo almacenar datos, a menudo implican explicar cómo escribir funciones CRUD individuales para una base de datos en la nube. Eso se debe al material metálico que puede ser muy poderoso, pero está muy lejos de hacer clic en unos pocos botones, que es lo que WordPress siente la mayor parte del tiempo.

Apuesto a que probablemente podría improvisar una configuración básica de comercio electrónico Jamstack con las API de Stripe, lo cual es genial. Pero luego me pongo nervioso cuando tengo que empezar a pensar en la gestión de inventario, zonas de envío, variaciones de productos y quién sabe qué más se complica en el mundo del comercio electrónico, lo que me hace desear tener algo súper sólido que lo hiciera todo por mí. .

A veces, nosotros, los desarrolladores, creamos sitios solo para nosotros (yo hago más de lo que me corresponde), pero yo diría que los desarrolladores en su mayoría crean sitios para otras personas. Entonces, la pregunta más importante es: ¿estoy construyendo algo que empodere a las personas para quienes lo estoy construyendo?

Puede lograr una buena experiencia como administrador de sitios sin importar qué, pero WordPress seguramente ha demostrado que cumple en ese departamento sin pedir mucho en términos de desarrollo personalizado.

Sin embargo, Jamstack tiene algunos trucos que me gustaría implementar en WordPress. Aquí hay uno importante para mí: contenido y actualizaciones enviados por los usuarios. Literalmente ahora tengo tres sitios web que se benefician de esto. Un sitio sobre conferencias, un sitio sobre tecnología sin servidor y un sitio próximo sobre codificación de fuentes. WordPress podría haber hecho un gran trabajo en esos tres sitios. Pero lo que realmente quiero es que la gente pueda actualizar y enviar contenido de una manera que yo pueda decir: Sí, se ve bien, fusionar. Al haber optado por un enfoque Jamstack, el contenido está en repositorios públicos de GitHub y cualquiera puede participar.

Creo que eso es genial. Ni siquiera requiere necesariamente que alguien del público conozca o comprenda Git o GitHub, ya que Netlify CMS tiene este concepto de Autoría Abierta, que mantiene toda la experiencia de contribución en el navegador con interfaz de usuario para la edición.

Usando ambos

Este es un tema importante que veo que se menciona mucho. Incluso el propio Netlify dice "No existe Versus".

Aquí está el trato:

• La "A" en "Jam" significa API. Utilice API para crear su sitio, ya sea en el momento de la construcción o en el lado del cliente.
• Los sitios de WordPress, de forma predeterminada, tienen una API REST (y también pueden tener una API GraphQL).
• Entonces, acceda a esa API para datos CMS en su sitio Jamstack.

Sí, totalmente. Esto funciona y la gente lo hace. Creo que es bastante genial.

Pero…

• Ejecutar un sitio de WordPress en algún lugar además de su sitio Jamstack significa... está ejecutando un sitio de WordPress además de su sitio Jamstack. Eso tiene un costo y una deuda técnica.
• A menudo no obtienes todo el valor de WordPress. Acceder a una API para obtener datos puede ser todo lo que necesita, pero este es un enfoque muy diferente para crear un sitio que crear un tema de WordPress. No obtendrás ninguno de los otros valores de WordPress. Pienso en situaciones como esta: encuentras un complemento interesante que agrega un elegante bloque Gutenberg a tu sitio. Eso “simplemente funcionará” en un sitio de WordPress, pero probablemente tenga algún comportamiento especial en el front-end que no funcionará si todo lo que estás haciendo es absorber el HTML de una API. Probablemente ponga en cola algunos scripts y estilos adicionales que usted deberá descubrir por su cuenta cómo incorporar dónde está alojado su front-end y por su cuenta mantener las actualizaciones.

Aquí hay algunos jugadores que tienen un enfoque único para "usar ambos":

• Frontity: un marco de React para WordPress. Lo ejecuta con un servidor Node detrás, además de su sitio de WordPress. El servidor Node representa React en HTML, por lo que obtienes representación del lado del servidor para todas las páginas, pero también estás construyendo un SPA .
• WP2Static: un complemento de WordPress que crea una versión estática de su sitio y puede implementarla automáticamente cuando se realizan cambios.
• Strattic: Ellos alojan el sitio dinámico de WordPress por usted (al que se refieren como "puesta en escena") y usted trabaja con WordPress normalmente allí. Luego, elige implementar y ellos también alojan una versión estática de su sitio para usted.
• Shifter: Shifter aloja el sitio de WordPress por usted. Tienes dos opciones: 1) ejecutarlo sin cabeza (para que solo accedas a la API, REST o GraphQL, para obtener datos) o 2) ejecutarlo estáticamente (para que cuando tengas todo en WordPress donde lo deseas, lo implementes). lo que crea una versión estática de su sitio, que también alojan, o puede enviarlo a otro lugar, por ejemplo, Netlify).

Hay muchas otras formas de integrar ambos. Aquí están nuestros propios Geoff y Sarah hablando sobre el uso de WordPress y Jamstack juntos mediante el uso de Vue/Nuxt con la API REST y el alojamiento en Netlify.

No usar ninguno

En caso de que esto no esté claro, hay muchísimas formas de crear sitios web. Si está creando un sitio Ruby on Rails, ese no es Jamstack ni WordPress. Se podría argumentar que se parece más a un sitio de WordPress en el sentido de que requiere un servidor y usted utilizar