Escrito por Javier

Del 'Efecto Alpine' ⛰️ a la Interactivity API: Comparando la reactividad en WordPress

He aprendido cómo pasar de la simplicidad de AlpineJS a la potencia nativa de la Interactivity API de WordPress para crear experiencias de usuario de alto nivel.

Si llevas tiempo desarrollando para WordPress igual es fácil que te hayas quedado, como yo, algo obsoleto. Como a muchos, el tránsito a bloques nos daba algo de pereza, pero la realidad es que, si no haces cosas con bloques, ¿por qué estar todavía desarrollando en WordPress? El frontend de WordPress siempre ha sido para mí jQuery y, de un tiempo a esta parte, casi exclusivamente AlpineJS si necesitaba algo de reactividad.

Recientemente, me propuse el reto de modernizar un grid de productos. Como el sitio web estaba hecho con un constructor visual, la herramienta habitual es crear un “shortcode”. Para ello mi primera opción, casi por instinto, fue Alpine.js. Pero en la WordCamp Valencia 2025, en una de las charlas, me descubrieron la Interactivity API y desde ahí empecé a tirar del hilo.

El romance con AlpineJS: Velocidad y simplicidad

Para los que venimos del desarrollo clásico o disfrutamos de herramientas como Tailwind, AlpineJS es como un soplo de aire fresco. Es lo que yo llamo el “Tailwind de JavaScript”. Te permite añadir lógica compleja directamente en tu HTML (o en tu render.php) sin salir del flujo de trabajo de PHP.

¿Por qué mola Alpine para bloques de WordPress?

  • Curva de aprendizaje moderada: Si sabes JavaScript y HTML, sabes Alpine.
  • Directivas en el DOM: Usar un x-data o un x-intersect para cargar productos al hacer scroll es casi insultantemente fácil.
  • Ligero: No necesitas un proceso de build pesado si no quieres; puedes cargar un script y empezar a jugar.

Sin embargo, cuando trabajas profundamente con el Core de WordPress te das cuenta de que Alpine tiene un “techo”. Si desarrollas en el 2026 para WordPress, necesitas una experiencia nativa en bloques. Especialmente si necesitas editores y personas que actualicen su web sin necesidad de código. Es aquí donde WordPress ha mejorado mucho y la Interactivity API ha sido un gran descubrimiento.


El gran descubrimiento: La Interactivity API

Aquí es donde la cosa se pone interesante. WordPress ha lanzado de forma nativa la Interactivity API (estabilizada en la versión 6.5). Al principio me acerqué con cautela, pensando que sería otra capa de complejidad técnica, pero la realidad es que es un proyecto con todo el sentido. A nivel técnico creo que el equipo de WordPress ha sido astuto. La primera vez que descubrí el código de la Interactivity API pensé: “Oye, esto es como Alpine”. Y, en efecto, fue una inspiración para ellos. Pero hoy el código de WordPress es React y para esto han optado por usar Preact. Más pequeño y capaz de aprovecharlo para gestionar el mayor reto: la comunicación entre componentes.

¿Qué hace a la Interactivity API superior para bloques nativos?

  1. Es nativa y segura: Olvida el eval(). Usa una sintaxis de atributos data-wp- que es 100% compatible con las políticas de seguridad (CSP) más duras del mercado.
  2. Hidratación en lugar de parpadeo: El servidor genera el HTML (SSR) y el JavaScript se “engancha” a él sin saltos visuales. Todo fluye mejor de lo esperado.
  3. Basada en Preact y Signals: Bajo el capó usa un sistema de señales. Esto significa que, si cambias un dato en una punta del sitio, todos los bloques que dependen de él se actualizan al instante de forma ultraeficiente.

De un botón de “Cargar más” al Scroll Infinito: Mi experiencia real

En mi última prueba, pasé de un botón clásico de carga de productos a un sistema de scroll infinito inteligente.

Lo que más me ha sorprendido es la capacidad de la Interactivity API para manejar el contexto. Puedes definir variables en PHP (data-wp-context), y el JavaScript las lee automáticamente sin necesidad de los trucos habituales para inyectar JS en PHP.

Durante el desarrollo me encontré con retos interesantes y también algo desconcertantes. ¿Lo mejor? Que esto ya lo puedes usar de forma amplia para la mayoría de cosas que hacías con AlpineJS en WordPress. Si no tienes esa necesidad de conseguir una experiencia nativa para el usuario, quizá no te haga falta, pero es estimulante ver cómo se incorporan tecnologías de frontend modernas en WordPress.


¿Con cuál me quedo?

Si estás haciendo un sitio rápido, con lógica muy aislada y no quieres pelearte con procesos de compilación o npm, AlpineJS sigue siendo una herramienta increíble.

Pero, si vas en serio con WordPress y el desarrollo de bloques, la Interactivity API es el camino. Me ha parecido una herramienta potente, madura y, sobre todo, muy bien pensada. WordPress ha dejado de ser ese sistema que se sentía “atado al pasado” para ofrecernos una experiencia de desarrollo frontend que no tiene nada que envidiar a frameworks modernos como Vue o Svelte.

Mi descubrimiento personal es que WordPress está en su mejor momento para los desarrolladores que buscan experiencias 100% nativas dentro del propio WordPress. No le tengas miedo a la Interactivity API; una vez que entiendes cómo fluyen los datos entre el PHP y el JS, te das cuenta de que el potencial para crear experiencias de usuario es excelente.