AEM y Edge Delivery Services: Devolver la Web a las raíces

No hace mucho tiempo, crear sitios web era bastante simple, como un archivo de texto y un sueño. Escribiste un poco de HTML, espolvoreaste algo de CSS y tal vez agregaste un poco de JavaScript vainilla si te sentías elegante ese día. El navegador hizo lo suyo, y boom: tenías un sitio web. Eso fue todo. Tenía que serlo, era todo lo que tu conexión de 56k podía manejar.

Luego llegó Internet de alta velocidad y V8: comenzaron los marcos, las herramientas de compilación, las bibliotecas y las infinitas capas de abstracción. En algún lugar en el torbellino de la agrupación, la transpilación y el polyfilling, Internet se alejó de su simplicidad original y olvidó lo poderosos que podían ser HTML, CSS y JavaScript simples.

Pero recientemente, mientras trabajaba con los servicios de entrega de Edge y la creación de documentos de Adobe, sentí algo familiar, como ese icónico ruido de apretón de manos de la conexión telefónica. EDS me llevó de vuelta a las raíces de la web: el contenido primero, impulsado por HTML, estilizado por CSS y rápido de forma predeterminada.

Esta publicación trata sobre ese sentimiento: recordar cómo se suponía que se debía construir la web. ¿Por qué? Porque en un mundo de front-ends inflados y pilas demasiado complicadas, la simplicidad importa más que nunca.

La Web Primitiva: Directa, Honesta, Rápida

Había belleza en lo sencilla que era la web primitiva. Abriste un editor de texto, escribiste algo de HTML, agregaste un poco de CSS en línea y, si necesitabas interactividad, tal vez agregaste una etiqueta de script con algo de JS vainilla. Ese era el flujo de trabajo. No hay pasos de compilación. Sin implementaciones. Sin dependencias. Lo subiste por FTP a un servidor y estabas bien.

Funcionó. Fue rápido. Cualquiera podía acceder a él. No se rompía en máquinas más lentas ni cargaba 3 MB de JavaScript minificado solo para representar un párrafo. Podrías "Ver el código fuente" y realmente aprender algo. Era crudo, lo que escribiste fue lo que se renderizó. No hay magia. Sin conjeturas.

Los desarrolladores tenían el control total y la barrera de entrada era baja. No necesitabas un título en informática ni un curso de 20 partes sobre los métodos del ciclo de vida de un marco. Solo necesitabas un navegador, un editor de texto y una idea.

Cuando la web engordó

Luego vino el motor V8 de Chrome y, con él, el renacimiento moderno de JavaScript. De repente, JS no era solo un juguete. Era rápido, potente y estaba en todas partes. Al principio, se sintió como magia... pero en realidad, acabamos de abrir la caja de Pandora.

Empezamos a hacer montañas con granos de arena. Un sitio que solía ser unos pocos archivos estáticos ahora necesitaba una pila de dependencias, un empaquetador, un compilador y la mitad de su RAM solo para escupir "Hola mundo". La instalación de NPM se convirtió en un ritual y no como su rutina de cuidado de la piel. Más como invocar a un demonio que te rompe a ti y a tu construcción.

Construimos capas sobre capas. Herramientas para gestionar nuestras herramientas. Abstracciones para cosas que nunca fueron complicadas en primer lugar. El mundo del front-end se obsesionó con las "aplicaciones" en lugar de los documentos. Y en algún lugar del caos, perdimos de vista lo básico: HTML para la estructura, CSS para el estilo y JS para el comportamiento.

Ingrese a la creación de documentos de Adobe: solo contenido

La creación de documentos de Adobe, ¿honestamente? Un soplo de aire fresco. A primera vista, parece que solo estás editando un documento de Word. Eso es porque... Más o menos lo eres. Está diseñado para la colaboración, es fácil de usar y fácil de aprender. Solo contenido limpio que sea fácil para que cualquiera contribuya.

Ese documento que estás editando no está simplemente en algún lugar esperando a ser copiado y pegado en WordPress. Se convierte en la página. Lo que escribes allí es lo que se entrega a la web, sin caos sin cabeza, sin rebajas para React a JSON a algo en tubería.

Es el contenido primero de la mejor manera posible. No es necesario que te las ingenies para escribir, simplemente escribes y ese cambio por sí solo es enorme. Significa que pasas menos tiempo tratando de unir los sistemas y más tiempo enfocándote en lo que realmente importa: el mensaje.

Qué es realmente el EDS y por qué funciona

Adobe Edge Delivery Services (o EDS, para abreviar; es posible que lo hayas visto flotando como Project Helix o Adobe Franklin) se siente como una revolución silenciosa. Sobre el papel, suena casi demasiado simple: contenido en un documento de Adobe DA (o Word, o SharePoint, o Google Docs), estructurado con tablas y encabezados, y luego entregado a la web usando bloques de JS y CSS vainilla. Sin herramientas de compilación. Sin scripts de implementación. Sin integraciones complejas de CMS. Solo tienes que escribir, guardar y enviar.

Y de alguna manera... Ese es el punto.

Es el tipo de configuración que te hace detenerte y preguntar: "Espera, ¿por qué complicamos esto?"

En lugar de convertir todo en una aplicación, EDS convierte los documentos en sitios web, tal y como funcionaba originalmente Internet.  El documento se centra en el contenido. Si necesitas diseño o interactividad, usas bloques. Cada bloque no es más que un trozo de lógica (Contenido + CSS + JS) que sabe interpretar la estructura del documento y convertirlo en HTML limpio y eficiente. Si puedes leer un documento de Google e inspeccionar una tabla, puedes averiguar cómo funciona un bloque.

Aún mejor, todo el código es de código abierto en GitHub, el flujo de trabajo de desarrollo está basado en Git y puede ver lo que está haciendo cualquier bloque en tiempo real con extensiones de navegador como AEM Sidekick. Es moderno en todos los aspectos que importan, sin estar agobiado por todas las cosas que no importan.

¿Por qué esto es realmente importante?

Toda esta simplicidad no es solo nostálgica, es práctica. Cuando eliminas el ruido y te enfocas en entregar HTML real con un poco de CSS y JS, todo mejora.

Los sitios de EDS son rápidos, como una puntuación de 100 Lighthouse, porque no hay un marco JS inflado que pese sobre las cosas. Estás enviando HTML, no arrancando una aplicación solo para mostrar una imagen de un gato.

¿Accesibilidad y SEO? Está ahí. Un HTML limpio significa que los lectores de pantalla y los motores de búsqueda realmente entienden tu contenido. Sin trucos, sin aros.

¿Experiencia de desarrollo? Dejé la universidad. No estás discutiendo configuraciones o depurando una compilación rota a las 2 a.m. porque algún paquete en lo profundo de la cadena se desvió. Construyes un bloque. Tú lo estilizas. Tocas la hierba.

¿Flujo de trabajo de contenido? Deja que se cocinen. Los escritores y editores trabajan en herramientas que ya conocen (Google Docs, Word, SharePoint) y sus actualizaciones se publican. Sin control de acceso. No hay tickets de Jira para "¿puedes agregar un espacio a esa oración?"

En resumen: es más rápido de crear, más fácil de mantener y más accesible para todos los involucrados, desde los desarrolladores hasta los autores y los usuarios.

Regreso al futuro

Es fácil pensar que el progreso significa añadir más herramientas, más capas, más abstracción. Pero a veces, lo mejor que puedes hacer es despojarte de todo y recordar lo que hizo grande a la web en primer lugar.

Adobe Document Authoring y EDS no solo facilitan las cosas, sino que las hacen más claras. Vuelven a dar a los desarrolladores y creadores de contenido un lenguaje común. Nos recuerdan que HTML, CSS y JS, solo lo básico, siguen siendo increíblemente poderosos.

Tal vez no se trate de reinventar la web. Tal vez se trate de quitarse de en medio.

¿Quieres profundizar en los servicios de entrega periférica?
Explore cómo puede transformar su entrega de contenido consultando nuestro blog sobre creación de documentos para Edge Delivery o escuche nuestro podcast de discusión en YouTube.

Sobre el autor

Episodios de podcast y publicaciones de blog