Llevamos tres años conviviendo con Gutenberg desde que llegó con WordPress 5.0 y nuestra postura ya no es la misma. Ha mejorado mucho en estabilidad y en capacidades, aunque todavía hay aspectos que nos siguen sacando de quicio como desarrolladores. Resistirse ya no tiene sentido: el tren ha salido y toca subirse o quedarse en el andén viendo cómo avanzan los proyectos.
Lo que ha mejorado de verdad
La primera gran victoria ha sido la estabilidad. Aquellos crashes constantes de los primeros meses son historia. Hoy el editor aguanta bloques anidados profundos sin pestañear y el rendimiento ha subido de forma notable, sobre todo después de las optimizaciones en el guardado y en el parsing de bloques.
La API de bloques ha madurado. Crear bloques personalizados con registerBlockType es bastante más cómodo que al principio. El soporte para block.json ha simplificado la vida: scripts, estilos y metadatos en un solo sitio. Además, los hooks como useBlockProps han reducido la verbosidad del código que teníamos que escribir hace tres años.
La experiencia de edición en pantallas grandes es buena. Los patrones de bloques, las variaciones y el directorio de patrones reutilizables han convertido lo que antes era un dolor en una herramienta realmente útil. Ya no tenemos que crear veinte bloques idénticos con clases distintas; un patrón resuelve el problema en segundos.
Lo que todavía duele
No todo es alegría. El editor sigue siendo terriblemente lento cuando el contenido pasa de las 1500-2000 palabras con bloques anidados. El famoso block editor lag sigue ahí, especialmente en instalaciones con varios plugins de bloques que compiten por inyectar sus scripts.
La compatibilidad con temas clásicos sigue siendo un campo de minas. Aunque theme.json ha traído orden, configurar correctamente colores, tipografías y espaciados entre un theme.json y los estilos del tema sigue siendo más complicado de lo que debería. A veces acabamos escribiendo CSS de emergencia solo para que el frontend se parezca al editor.
Otro punto negro es la accesibilidad. Aunque han mejorado, todavía hay bloques nativos que generan markup problemático o que no gestionan bien los estados de foco. Como desarrolladores que entregamos proyectos a clientes finales, esto nos genera más trabajo de corrección del que nos gustaría admitir.
Y luego está la curva de aprendizaje para clientes no técnicos. Aunque el editor es más intuitivo que Classic Editor para usuarios nuevos, los clientes veteranos siguen odiando el concepto de bloques. Cambiar de mentalidad de “página como documento” a “página como composición de piezas” ha sido más traumático de lo esperado.
Bloques personalizados: la parte que más nos gusta
Aquí es donde realmente brilla Gutenberg para quienes desarrollamos. Crear bloques a medida ya no es un infierno. Combinando block.json, componentes de @wordpress/block-editor y un poco de React moderno podemos entregar interfaces de edición que hace tres años parecían ciencia ficción.
Nos gusta especialmente la posibilidad de crear bloques dinámicos que renderizan en servidor. El control granular sobre lo que se envía al frontend nos permite optimizar el HTML entregado y mantener la velocidad de carga. Además, el sistema de atributos y el uso de InnerBlocks nos da una flexibilidad brutal para construir sistemas de diseño coherentes.
En proyectos grandes hemos creado bibliotecas internas de bloques que reutilizamos entre clientes. El mantenimiento es mucho más sencillo que con shortcodes o con page builders tradicionales. Un cambio en el bloque se propaga a todos los sitios sin romper nada (casi nunca).
Por qué ya no tiene sentido resistirse
La resistencia activa a Gutenberg nos ha costado tiempo y dinero. Durante los dos primeros años muchos estudios siguieron ofreciendo Classic Editor como opción principal. El resultado fue una deuda técnica creciente y clientes con sitios que se iban quedando obsoletos.
Hoy el ecosistema se ha movido claramente hacia Gutenberg. Los temas modernos se construyen pensando en él. Los plugins importantes ya no ofrecen alternativas serias al editor de bloques. Incluso herramientas externas como los constructores visuales están integrando o adaptándose al paradigma de bloques.
Desde el punto de vista técnico, luchar contra Gutenberg es luchar contra la dirección que ha tomado el propio WordPress. El equipo de desarrollo ha invertido recursos masivos en el proyecto y eso no va a cambiar. Aceptarlo no significa rendirse, significa dejar de perder energía en batallas que ya están decididas.
Además, reconocer sus virtudes no nos impide criticar sus defectos. Podemos construir con bloques y seguir exigiendo mejoras en rendimiento, accesibilidad y experiencia de desarrollo. Esa es, de hecho, la postura más madura: usar la herramienta, mejorarla desde dentro y no fingir que el Classic Editor va a volver.
Conclusión sin moraleja barata
Tres años después, Gutenberg es una herramienta imperfecta pero claramente superior para la mayoría de proyectos que afrontamos. Nos obliga a pensar en componentes, en reutilización y en sistemas de diseño. Nos obliga también a mantenernos actualizados y a aprender React, algo que al final ha resultado beneficioso para nuestro perfil como desarrolladores.
Los dolores siguen ahí. El editor sigue siendo lento en ciertos escenarios y la experiencia de edición no es todavía tan pulida como nos gustaría. Pero los beneficios superan con creces los problemas, especialmente si invertimos tiempo en construir buenos bloques y patrones.
Así que sí, seguimos quejándonos en los grupos de Telegram. Pero cuando llega un proyecto nuevo, abrimos el editor de bloques sin pensarlo dos veces. Y eso, al final, es lo que cuenta.