Implicaciones de WordPress unirse al protocolo de bloque
Publicado: 2022-03-10Matt Mullenweg (creador de WordPress) ha expresado su interés en que el editor de WordPress cumpla con el Protocolo de bloques, una especificación lanzada recientemente que tiene como objetivo que los "bloques" sean portátiles entre aplicaciones.
Cuando me enteré del interés de Matt, me emocioné mucho, ya que tal desarrollo podría producir varias consecuencias positivas para WordPress y otros actores también. Mi entusiasmo proviene de lo que sucedió con GraphQL, donde el lanzamiento de servidores, clientes y herramientas que se adhieren a una especificación común ha producido un rico ecosistema; y de mi propio desarrollo de un complemento que podría admitir nuevas funciones a través del protocolo.
En este artículo, analizaré estos y varios otros posibles resultados. Pero antes de hacerlo, exploremos el contexto de la historia: qué es un bloque, qué pretende lograr el Protocolo de bloque y cómo se conecta todo a WordPress.
¿Qué es un bloque?
Cuando trabajamos con bibliotecas basadas en JavaScript, como React o Vue, trabajamos con "componentes" que son fragmentos de código (generalmente compuestos por HTML, estilos CSS y JavaScript) agrupados. Un componente representa un diseño definido o produce una funcionalidad específica, como un carrusel de imágenes, un calendario de eventos o un encabezado simple. Para representar el contenido, el componente puede obtener datos del servidor a través de una llamada a la API, o hacer que los datos sean proporcionados a través de accesorios por algún componente ancestro que lo envuelva. Al inyectar sus datos, el componente se vuelve reutilizable, capaz de producir diferentes resultados para diferentes contextos o aplicaciones.
Un "bloque" también es un componente, pero es de alto nivel, afirma un propósito definitivo y define los requisitos para producir el diseño o la funcionalidad deseados. Es el componente más externo de la jerarquía de componentes que se envuelven entre sí, por lo que tiene una vista de pájaro de ellos.
Podemos jugar con los componentes cuando usamos Notion, donde cada acción (ya sea escribir texto, agregar una lista con viñetas, crear tablas o cualquier otra cosa) se logra insertando uno u otro bloque:
Un bloque es un concepto, no una tecnología. Se puede implementar en cualquier idioma: no solo JavaScript para impulsar a los clientes, sino también un idioma del lado del servidor para representar un diseño. Los bloques no deben confundirse con los componentes web, que es una colección de tecnologías para producir componentes. Tampoco son mutuamente excluyentes: podemos usar componentes web para crear un bloque.
Tomando una analogía del mundo ágil: si un MVP, o Producto Mínimo Viable, es el trabajo mínimo para lanzar y comercializar un proyecto comercial, podríamos pensar en el bloque como un MUC, o Componente Mínimo Utilizable, como una unidad básica de trabajo que da coherencia y personalidad a una aplicación.
¿Qué es el protocolo de bloque?
Los componentes son bastante reutilizables. Por ejemplo, buscar "componente de reacción" en npm producirá muchas bibliotecas que ofrecen componentes que podemos importar inmediatamente a nuestras aplicaciones de React.
Los bloques, sin embargo, son una historia diferente, porque en su mayoría están diseñados para alguna aplicación específica. Si bien el bloque debe proporcionar los medios para interactuar con él (como ofrecer una API para inicializarlo y renderizarlo, o exponer un esquema JSON que describa qué datos necesita como entrada), estos medios generalmente dependen de la aplicación donde vive el bloque. , por lo que no podemos reutilizar un bloque entre aplicaciones.
Ahí es donde entra en juego el Protocolo de bloques. Proporciona una especificación para que los bloques y las aplicaciones satisfagan, con el objetivo de permitir que los bloques se incrusten en cualquier aplicación, no solo para la que fueron diseñados. Al igual que con los componentes, los bloques podrían volverse reutilizables en todas las aplicaciones.
Bloques reutilizables y WordPress
Desde la versión 5.0 de diciembre de 2018, la experiencia predeterminada en WordPress para crear contenido ha sido a través de bloques. Desde su versión 5.9 lanzada recientemente, esta experiencia se ha ampliado a la creación de diseños de sitios web a través de la edición completa del sitio (FSE). La experiencia moderna para crear contenido y un tema para WordPress ahora es a través de bloques.
Cuando Joel Spolsky presentó recientemente el Block Protocol al mundo, lo hizo desde su blog con tecnología de WordPress. Mientras explicaba cómo usaba bloques para componer su publicación, sugirió que los bloques deberían ser reutilizables en toda la web. Esta fue una sugerencia directa de que los bloques de WordPress deberían ser reutilizables en toda la web, a lo que Matt Mullenweg accedió de inmediato.
Analicemos a continuación qué consecuencias podemos prever de tal desarrollo si llegara a suceder.
¿Quién utilizará el protocolo de bloque?
Esta es la descripción de Joel de cómo surgió el Block Protocol:
“[La implementación de un bloque por diferentes aplicaciones] es completamente patentada y no estándar.
Pensé, ¿no sería genial si los bloques fueran intercambiables y reutilizables en la web?
[...] Los usuarios pueden querer usar un bloque más elegante que vieron en WordPress o Medium o Notion, pero mi editor no lo tiene. Los bloques no se pueden compartir o mover fácilmente, y nuestros usuarios están limitados a las funciones y capacidades que tuvimos tiempo de volver a implementar”.
Si bien estoy 100 % de acuerdo con la motivación de Joel, creo que esperar que Notion o Medium implementen sus bloques mediante un protocolo compartido públicamente no es realista. ¿Por qué lo harían? Por supuesto, quieren que sus bloques sean propietarios. Si Medium pusiera sus propios bloques a disposición de cualquier aplicación para incrustarlos, cualquiera podría ofrecer de la noche a la mañana un clon de Medium y desviar el tráfico de ellos. Lo mismo para Noción. Al ser plataformas comerciales que apuntan a ganar usuarios en función de sus funciones avanzadas y su excelente experiencia de usuario, no hay nada que les permita regalar su tecnología (es decir, aún podrían cumplir con el protocolo para su propio uso interno, pero entonces nosotros, extraños, no se beneficiarán de ella).
Entonces, ¿quién más, además de WordPress, puede querer cumplir con el Block Protocol? ¿Quién se beneficiará de ello?
Mi impresión es la siguiente:
- Equipos sin un gran presupuesto
En lugar de desarrollar sus propios bloques desde cero (lo que requiere mucho esfuerzo y, como tal, exige un equipo dedicado), se podría construir un sitio web utilizando bloques desarrollados por otra persona; el equipo podría simplemente personalizar los bloques para su propia aplicación y posiblemente contribuir al código fuente abierto de los bloques. - Aplicaciones que necesitan ponerse al día para ofrecer una experiencia de usuario atractiva
Medium y Notion son populares porque su experiencia de usuario es atractiva. Si pudiéramos proporcionar una experiencia de usuario similar para nuestros sitios web (y por muy poco o ningún costo), ¿por qué no deberíamos hacerlo?
Esto no se limita necesariamente a sitios web pequeños, sino que también puede ser el caso de sitios web populares que se están quedando atrás en la carrera de bloques. Por ejemplo, hace un tiempo me di cuenta de que Mailchimp estaba experimentando con un editor moderno basado en bloques para redactar boletines (ya no puedo encontrar este nuevo editor... ¿se lo han quitado?). Lo probé, pero tenía errores, así que volví al editor clásico de panel dividido (que también admite bloques pero de un tipo diferente, no editable en el lugar). ¿Puede Mailchimp beneficiarse del uso de bloques ofrecidos por WordPress?
- Sistemas de gestión de contenido
Al igual que WordPress, otros CMS también pueden beneficiarse al ofrecer bloques listos para usar para crear aplicaciones. De hecho, Drupal Gutenberg ha intentado llevar el editor de WordPress a Drupal. Gracias al Block Protocol, esta tarea podría ser más fácil de realizar. - Proyectos de código abierto
Al igual que los componentes disponibles a través de npm, si los bloques fueran reutilizables, entonces es solo cuestión de tiempo antes de que la comunidad comience a construir bloques y ofrecerlos libremente como código abierto (ya sea a través de GitHub, Block Hub o en otro lugar) para el beneficio de todo el mundo.
¿Cómo se beneficiarán los demás si WordPress se une al protocolo de bloques?
Acabamos de explorar quién puede beneficiarse y, como tal, puede querer unirse al Block Protocol. Pero además, podemos preguntarnos: ¿Cómo podrían beneficiarse si WordPress se une al Block Protocol?
Esta es mi impresión:
- Acceso a los bloques de WordPress
La respuesta más obvia es que todos los bloques actualmente disponibles para WordPress (a través del editor y FSE) también estarán disponibles para sus propias aplicaciones, ya sea que estén basadas en WordPress o no. - Unirse al proceso dirigido por la comunidad para crear bloques
La creación de bloques es un proceso que requiere mucho tiempo y esfuerzo. Le tomó al proyecto Gutenberg 5 años producir el Full Site Editor, y todavía es un trabajo en progreso. Y la cantidad de personas involucradas con cualquier nueva versión de WordPress es de cientos, y la última superó los 600 colaboradores.
La comunidad de WordPress invierte continuamente una gran cantidad de recursos en comunicación para asegurarse de que este proceso transcurra de la mejor manera posible, e incluso incluye reuniones retrospectivas para analizar qué salió mal y mejorarlo para los próximos lanzamientos.
¿Cuántas organizaciones pueden igualar este proceso bien pulido de gestionar cientos de personas para producir un recurso común? Por esta razón, unirse al esfuerzo liderado por la comunidad de WordPress para producir bloques, en lugar de hacerlo solo, podría beneficiar a todos. - Un gran adoptante da credibilidad y tracción al protocolo
El Protocolo de bloques apenas se ha publicado y todavía es un borrador. ¿Quién lo usará? ¿Cómo generará el proyecto la aceptación de los interesados potenciales? Tener el respaldo de WordPress envía una señal fuerte y crea confianza para que otros se unan al saber que el proyecto tendrá colaboradores y apoyo a largo plazo.
¿Qué hay para WordPress?
Para que WordPress sea relevante durante los próximos 15 años, debe sobrevivir en el mundo de las aplicaciones modernas y altamente dinámicas. Por eso, a partir de la versión 5.0 en adelante, WordPress se ha embarcado en un proceso de modernización, que lo ha visto metamorfosear de ser una aplicación bastante estática, renderizando diseños basados en plantillas PHP en el lado del servidor a una todavía estática pero menos. Entonces, la aplicación que obtiene datos de una API REST y usa bloques de JavaScript para representar contenido y, desde la última versión 5.9, diseños.
Nota : Todavía no es muy dinámico, porque los diseños se generan de antemano en wp-admin y se guardan en la base de datos, en lugar de generarse en el cliente como reacción a alguna acción del usuario.
Esta transformación ha tardado un tiempo en materializarse, ya que comenzó en 2015 cuando Matt Mullenweg le pidió a la comunidad de WordPress que "aprendiera JavaScript en profundidad". Unirse al Block Protocol sería otra parada en el viaje de modernización de WordPress.
Veamos qué beneficios podría obtener de ello.
Mantener el crecimiento de su cuota de mercado
A día de hoy, WordPress impulsa el 43% de todos los sitios web. Si bien su éxito es innegable, aún no es suficiente para Matt Mullenweg, quien ha expresado su deseo de que WordPress alcance el 85% de la cuota de mercado. (Juzgar si esta postura es correcta o incorrecta queda fuera del alcance de este artículo).
Ahora bien, podemos preguntarnos, ¿qué es exactamente un sitio de WordPress? En el pasado, con su arquitectura monolítica basada en PHP, la respuesta fue bastante clara. Pero hoy en día construimos sitios web basados en una pila que comprende múltiples tecnologías. Es posible que tengamos un backend de WordPress alimentando un frontend de React, alimentándolo con datos a través de la API REST de WP. ¿Es un sitio de WordPress?
La respuesta es: no lo sé, pero posiblemente tampoco importe. Si WordPress es una de las tecnologías en la pila, seguirá creciendo. Hasta ahora, WordPress solo podía asumir el rol del CMS, administrando los datos para alimentar al cliente. Pero ahora, gracias al Protocolo de bloques, WordPress podría asumir un nuevo rol: proporcionar bloques para potenciar la interfaz de cualquier aplicación.
En este escenario, WordPress tomaría un papel más importante en la creación de sitios. Lo que llevaría a que WordPress siga ganando cuota de mercado y se afiance más en el conjunto de herramientas de desarrollo web, lo que dificulta que se vuelva irrelevante.
Mayor grupo de colaboradores
Al usar los bloques ofrecidos por WordPress, los desarrolladores que normalmente no usan WordPress se familiarizarán con él y, con suerte, lo apreciarán y se convertirán en contribuyentes del código de fuente abierta. Esto es importante ya que el grupo de colaboradores será más grande (por ejemplo, JavaScript tiene alrededor de 3 veces más desarrolladores profesionales que PHP) y traerá un conjunto más diverso de habilidades.
Mayor disponibilidad de bloques
No hace falta decir que el concentrador de bloques funcionará en ambos sentidos: WordPress pondrá sus bloques a disposición de todos los demás, pero también los bloques codificados para otra persona estarán disponibles para potenciar los sitios de WordPress.
Por ejemplo, si Mailchimp decide unirse para usar bloques de WordPress para potenciar su editor de boletines, y luego los mejora o produce y lanza sus propios bloques, estos estarán disponibles para los complementos de WordPress que crean y envían boletines.
Desacoplando el editor de WordPress de Gutenberg
Gutenberg es el proyecto que sienta las bases del editor de bloques en WordPress. Proporciona un motor que permite interactuar con bloques. Por ejemplo, toma la salida de los métodos de edit y save de un bloque, para representar el HTML en el editor y guardarlo en la base de datos.
Sin embargo, el editor de bloques no necesita estar acoplado a Gutenberg. Después de todo, un "bloque" es un concepto y Gutenberg es una implementación específica. El Block Protocol se puede colocar perfectamente entre ellos, actuando como el enlace entre el concepto y la implementación.
Como resultado, ahora se puede eliminar Gutenberg y cualquier otro motor de implementación puede ocupar su lugar, brindando una experiencia diferente que aún funciona con los mismos bloques.
Una consecuencia interesante es que WordPress puede beneficiarse de esta arquitectura, porque Gutenberg no vive en todas partes en el sitio de WordPress, sino solo en wp-admin . En otras palabras, el sitio de cara al público que construimos usando WordPress no depende en sí mismo de Gutenberg; en cambio, simplemente imprime el HTML creado con Gutenberg en el backend. Es por eso que mencioné anteriormente que los sitios de WordPress aún no son muy dinámicos.
Al usar el protocolo de bloques para comunicarnos con bloques, no necesitaríamos tener Gutenberg en el lado del cliente para usar bloques. En cambio, podríamos tener una aplicación React que represente los bloques directamente y en función de las interacciones del usuario, lo que hace que el sitio sea más dinámico.
La misma idea puede funcionar en wp-admin , en cualquier página donde Gutenberg aún no esté disponible (al menos hasta que lo esté). Por ejemplo, si quisiéramos proporcionar una página de configuración que funcione completamente con bloques para nuestros complementos, con el Protocolo de bloques podríamos usar React para representar los bloques de configuración necesarios (calendarios, mapas interactivos, controles deslizantes, menús desplegables con opciones o cualquier entrada adecuada) y agregue un poco de lógica PHP para guardar los datos en la tabla wp_options .
Incrustación de bloques en el sitio de cara al público
Llevando la sección anterior un poco más allá, el bloque real podría integrarse en el sitio público para que los usuarios interactúen con él.
Hay un sinfín de casos de uso para esta función, que incluyen:
- mostrar un calendario para que los usuarios reserven espacios para reuniones, como lo hace Calendly;
- permitir a los usuarios dibujar algo, como lo hace Brush Ninja, o jugar juegos, como con Block-a-saurus;
- hacer que los usuarios manipulen imágenes, como será posible con la próxima experiencia multimedia renovada con FSE.
Otro ejemplo proviene de mi propio complemento de WordPress, y poder admitirlo es la razón por la que estoy entusiasmado con el Protocolo de bloque. La API de GraphQL para WordPress se envía con un bloque de cliente de GraphiQL que permite redactar la consulta persistente de GraphQL:
Al mismo tiempo, inserto el cliente GraphiQL en el sitio de documentación para que los visitantes jueguen con él y descubran cómo funciona el servidor GraphQL:
Con el Protocolo de bloque, esta idea de exponer el cliente GraphiQL en el sitio de documentación también podría otorgarse a los usuarios de mi complemento. Luego, podrían simplemente incrustar el bloque GraphiQL en sus propios sitios públicos para documentar cómo recuperar datos de sus propias API de GraphQL para sus propios visitantes.
Ayudar en la fase de "colaboración" de Gutenberg
Poder incrustar bloques en el sitio público también podría ser útil para la fase 3 del editor de bloques, cuyo objetivo es optimizar la colaboración para producir una experiencia de coautoría similar a Google Docs o Dropbox Paper.
Cuando recibo un enlace a Dropbox Paper, no necesito iniciar sesión para visualizar su contenido:
De manera similar, podríamos tener un lado del cliente que pueda representar e interactuar con bloques, de modo que los usuarios que no hayan iniciado sesión también puedan proporcionar comentarios. Estos visitantes no necesitarán acceder al wp-admin del sitio, por lo que estaremos maximizando las oportunidades de colaboración.
Mejorar aún más el concepto de "API única para todo"
El concepto de bloque se introdujo como una forma de unificar todas las diferentes formas de agregar contenido en el sitio de WordPress. En el pasado, al usar el editor "clásico", podíamos agregar código dinámico a través de un widget o un código abreviado y manipular la apariencia del sitio a través del personalizador. El bloque reemplaza todos estos diferentes mecanismos al proporcionar una "única API" para producir y personalizar todo el contenido del sitio.
Esta simplificación ha ocurrido en la interfaz de usuario. Sin embargo, los bloques en sí mismos no siempre brindan una única forma de manejarlos, ya que los bloques dinámicos requieren que se represente la misma salida en JavaScript y PHP (el primero para generar el HTML para el editor, el último para imprimirlo en el sitio de cara al público). Esta situación es motivo de angustia para los desarrolladores y agrega barreras para los nuevos colaboradores.
Ha habido varias propuestas para abordar este problema (brillantemente resumidas en esta discusión), pero ninguna de ellas es lo suficientemente convincente. El complemento WooCommerce también se ha ocupado de un problema similar, pero su solución me parece un poco complicada. Idealmente, el CMS debería proporcionar un mecanismo para crear código SECO sin necesidad de hacks.
El Block Protocol podría proporcionar una mejor alternativa. Si el desarrollador no desea volver a codificar la misma lógica en PHP, la representación del bloque podría realizarse en la interfaz utilizando el mismo bloque. Esto se basaría en la representación del lado del cliente (CSR) en lugar de la representación del lado del servidor (SSR), que no siempre se recomienda (ya que puede afectar la indexación del contenido por parte de los motores de búsqueda), pero la opción de decidir por cualquiera de ellos sería descansar en el desarrollador.
Como beneficio adicional, esta solución también podría atraer a más desarrolladores de React a usar WordPress.
Uso de desarrollos desde fuera del reino de WordPress
Como mencioné anteriormente, adherirse a un protocolo compartido podría conducir a desarrollos no coordinados que producen un ecosistema rico, como sucedió con GraphQL.
Por ejemplo, SpectaQL es un generador de documentación para las API de GraphQL. Con solo adherirse a la especificación GraphQL, este proyecto permite que la API se documente automáticamente, lo que requiere muy poco esfuerzo por parte del desarrollador.
Adherirse al Block Protocol podría producir efectos similares. Podemos prever que algunos proyectos pueden extraer automáticamente la información de block-metadata.json y producir un sitio estático que documente todos los bloques. Esta misma idea se está implementando actualmente para Gutenberg. Si algún proyecto ya abordara este trabajo para el Protocolo de bloques, Gutenberg podría aprovecharlo y liberar a sus colaboradores para que se encarguen de otras tareas.
Soporte mejorado para GraphQL
La otra razón que me emociona particularmente es que los servidores GraphQL para WordPress (WPGraphQL y mi propia API GraphQL para WordPress) actualmente no pueden proporcionar un soporte óptimo para Gutenberg, porque block.json no declara el tipo real de una propiedad de objeto o matriz. Por ejemplo, un bloque en Gutenberg puede declarar que una propiedad es de tipo array , pero GraphQL necesita saber que es una array de tipo String .
El Protocolo de bloque recomienda encarecidamente definir el tipo final de la propiedad:
Cuando estén disponibles, los bloques entityTypes esperar y manejar un campo de tipo de entidad que contenga definiciones de tipos de entidad para cualquier entidad enviada a los bloques.Por lo tanto, si los bloques de WordPress se adhirieran al Protocolo de bloques, su esquema JSON se actualizaría para proporcionar esta información, y los complementos de GraphQL podrían recuperar datos de bloques sin recurrir a hacks.
Terminando
En este artículo, he discutido algunas posibles consecuencias de que WordPress se una al Block Protocol, sugiriendo que producirá resultados positivos. Sin embargo, no he mencionado cuán factible es que suceda.
¿Es técnicamente posible? ¿Se puede hacer sin romper la compatibilidad con versiones anteriores? ¿Los beneficios potenciales superan el esfuerzo requerido? ¿Tiene sentido que exista un protocolo de bloque en primer lugar o los diferentes requisitos de diferentes aplicaciones no se pueden conciliar a nivel de bloque?
Todas estas preguntas (y muchas otras) deben tener una respuesta antes de tomar la decisión de unirse o no al Block Protocol. Como Matt Mullenweg ha expresado su interés, ahora es el momento de que la comunidad evalúe y decida si WordPress debe detenerse y recargar combustible en este nuevo puerto en su viaje de modernización, o saltearlo y continuar navegando hacia adelante.