aprender_de_la_primera_iteracion_fallida

Saber escoger la herramienta correcta para lograr un resultado concreto es una de las habilidades más importantes que debe desarrollar un ingeniero de software.

Este principio de desarrollo, tan básico como profundo en sus consecuencias, fue el que comenzó a perfilar mi manera de pensar durante los últimos dos semestres de mi maestría, justo cuando empezaba a conceptualizar escritura::extendida.

En esta entrada y la siguiente quiero contarles cómo, tras una primera iteración fallida, mucha investigación y una serie de experimentos, terminé por abandonar WordPress y adoptar Astro para hacer realidad este sitio.

Hasta entonces, mi experiencia en diseño web había sido mínima y mediada casi por completo por herramientas visuales que no utilizaban código, como Squarespace, que años atrás había utilizado para construir mi portafolio artístico.

En aquel momento, diseñar un sitio web era tan facil como seleccionar una plantilla prediseñada, ajustar unos cuantos bloques de contenido y dejar que la interfaz definiera por mí la estructura del sitio. Mi objetivo para ese sitio era simple: poder mostrar un reel videográfico y ejemplos de mi fotografía.

Ese es precisamente el territorio donde brillan las plataformas de diseño sin código; crean sitios predecibles, generalistas y visualmente coherentes sin obligar al usuario a involucrarse con la arquitectura subyacente.

Pero cuando escritura::extendida empezó a tomar forma más real, entendí que ese tipo de herramientas no podría sostener el proyecto literario y experimental tal y como lo imaginaba. Yo no buscaba un sitio web clásico que simplemente mostrara bloques de texto. Más bien, buscaba un sitio donde el texto mismo pudiera ser afectado por el código de diversas formas, quizás no previstas por los diseñadores de estas herramientas.

Este tipo de experimentación no cabia en los moldes rígidos que ofrecen páginas de diseño web sin codigo como Squarespace o Wix. La propuesta de valor de estos sitios es la reproducibilidad del caso común; y lo que yo buscaba era precisamente lo contrario, un uso de caso no común.

Fue luego durante mis clases de ingeniería de software, cuando empece a desarrollar aplicaciones con herramientas programaticas como Django, que descubrí el verdadero alcance creativo de HTML, CSS y JavaScript. Comprendí que la web puede no solamente ser un espacio donde se muestra contenido, sino un medio donde el contenido mismo puede comportarse como un sistema organico. Esa revelación marcó un límite claro entre lo que permiten las herramientas visuales y lo que exige un proyecto que trata el texto como materia estética.

Un sitio en el que el texto mismo tuviese una materialidad dinámica:

Frases que desaparecen ante la presencia del cursor.

Palabras que vibran.

Sin embargo, a pesar de haber empezado a desarrollar estas intuiciones, estas no guiaron el que fue el primer paso técnico para implementar el sitio. La primera iteración de escritura::extendida, de hecho, tomó un rumbo inesperado. Y fue un rumbo equivocado.

wordpress

Aunque sea difícil de creer, el primer borrador de este blog nació en WordPress. El atractivo inicial de la herramienta era evidente: como Content Management System (CMS), Wordpress prometía abstraer todo lo relacionado con despliegue, infraestructura y mantenimiento. Podía centrarme en escribir, organizar y publicar, sin pensar en el servidor que había detrás. En esa etapa temprana, esa comodidad me resultó profundamente seductora y esa abstracción me pareció la forma ideal de “simplemente empezar a escribir” mientras dejaba que las ideas empezaran a tomar forma.

Tras una breve lectura sobre las capacidades de los bloques HTML que WordPress incorpora, supuse que tendría suficiente control para empezar a experimentar con pequeñas transformaciones de texto que ya imaginaba como experimentos literarios. Pero muy pronto descubrí los límites de ese modelo.

Como CMS, WordPress está diseñado para garantizar consistencia y estabilidad: sus bloques visuales operan dentro de un marco rígido que mantiene la integridad del sistema. Y aunque permite insertar fragmentos de HTML o JavaScript, no ofrece un acceso profundo a la estructura del documento ni al ciclo de renderizado que define cómo aparece realmente el contenido en el navegador.

Esto no es un defecto; es precisamente cómo funciona un CMS. Pero para mí, en ese momento, sí era una limitación.

La limitación se volvió evidente apenas terminé el borrador de la primera publicación. Tras haber trabajado con frameworks más programáticos y declarativos como Django, WordPress se sentía tedioso e innecesariamente incómodo para lo que yo buscaba: una experiencia fragmentada en paneles, menús y una sucesión constante de clics que interrumpían cualquier flujo experimental. Su editor por bloques, pensado para componer páginas de manera visual y predecible, dificultaba intervenir el texto con precisión; cada variación requería rodeos, configuraciones ocultas o soluciones ad hoc. La plataforma respondía, en última instancia, a un paradigma orientado a la publicación convencional, no a la manipulación directa del texto como material estético, reactivo y maleable.

Fue dentro de esa tensión donde surgió la pregunta que cambiaría el rumbo del proyecto:

¿Cuál es el fundamento técnico que hace que WordPress dificulte hacer lo que quiero hacer?

Parte de la respuesta estaba en la arquitectura misma del sitio que WordPress genera y hace visible al usuario. WordPress es, en esencia, un sistema que produce sitios web dinámicos, lo cual implica que el contenido nunca existe como un documento HTML prerenderizado y estable. Para tratar de entender la diferencia, investigué mucho sobre las diferencias entre los sitios de web estáticos y sitios de web dinámicos.

wordpress_como_sitio_web_dinámico

Como sitio de web dinámico, Wordpress construye cada pagina “al vuelo”: el servidor ejecuta código PHP, consulta una base de datos MySQL, recupera el contenido solicitado, aplica la jerarquía de plantillas del tema activo y solo entonces genera el HTML final que recibe el navegador.

Este proceso, que sin duda es eficiente para gestionar contenido, introduce una distancia del documento final y crea un entorno donde el escritor o desarrollador nunca opera directamente sobre el HTML definitivo. El archivo que llega al lector no es el mismo que uno edita, sino el resultado ensamblado de múltiples capas: plantillas de PHP, estilos del tema, bloques del editor, configuraciones internas del CMS y, en muchos casos, plugins que alteran el árbol del DOM antes de que sea entregado. Ese ensamblaje dinámico está diseñado para garantizar flexibilidad y compatibilidad, pero actúa como una barrera cuando se intenta tener control fino sobre el comportamiento del texto.

/* Ejemplo de cómo WordPress genera un documento HTML a partir de un post */
<?php
// page.php dentro de un tema de WordPress
get_header();

if ( have_posts() ) :
  while ( have_posts() ) : the_post(); ?>
    <article class="entry-content">
      // el contenido del post, que tipicamente se obtiene de una base de datos 
      // y pasa por un pipeline de procesamiento antes de ser renderizado.
      <?php the_content(); ?> 
    </article>
  <?php endwhile;
endif;

get_footer();

<!-- Editar en HTML es mas facil y directo -->
<!DOCTYPE html>
<html lang="es">
  <head>
    <meta charset="utf-8" />
    <title>Ejemplo</title>
    <style>
      p { max-width: 65ch; line-height: 1.6; }
    </style>
  </head>
  <body>
    <p>
      Este párrafo existe exactamente como será leído.
    </p>
  </body>
</html>

Además de esto, la arquitectura de WordPress introducia una serie restricciones prácticas:

• Los bloques de su editor propietario encapsulan el contenido en estructuras HTML predefinidas, difíciles de modificar desde dentro.
• Muchas partes del documento se generan mediante funciones internas del CMS, que no exponen puntos de intervención precisos para manipulación estética.
• El pipeline dinámico del servidor impide prever con exactitud el HTML final, dificultando la aplicación de transformaciones complejas o comportamientos experimentales.
• El DOM generado por WordPress puede variar según plugins, temas o configuraciones internas, lo que reduce la estabilidad del entorno cuando se busca trabajar con animaciones, transformaciones o efectos sensibles a la estructura del documento.

En otras palabras: el texto en WordPress no es un objeto transparente y manipulable, sino el resultado de un sistema pensado para publicar contenido convencional de forma robusta y consistente. Ese modelo es ideal para sitios con usuarios, comentarios o un flujo editorial complejo, pero se vuelve contraproducente cuando lo que se desea es intervenir el texto de manera directa, tratándolo como un material estético.

la_decisión_de_abandonar_wordpress

Entendí entonces que Wordpress claramente dificultaba el tipo de experimentación que era fundamental para escritura::extendida. No era simplemente por una limitación superficial, sino por su propia filosofía arquitectónica: el contenido en Wordpress es gestionado y administrado, no interpretado como un espacio donde el código pueda actuar en el mismo plano que el contenido literario.

Para muchos proyectos, WordPress sin duda es la herramienta ideal, pero para escritura::extendida claramente no lo era.

El sitio no necesitaba procesar usuarios ni enviar contenido personalizado: lo que necesitaba era una superficie de experimentación directa, donde el texto pudiera reaccionar al entorno sin pasar por un sistema cerrado. Comprender esta diferencia arquitectónica fue clave para tomar una decisión informada.

Fue lo que me permitió abandonar WordPress sin nostalgia y empezar a buscar una herramienta cuya filosofía coincidiera con la del proyecto. Esa búsqueda es el punto de partida de la siguiente entrada.