AEM e Edge Delivery Services: riportare il Web alle radici

Non molto tempo fa, creare siti web era piuttosto semplice, come un file di testo e un sogno. Hai scritto un po' di HTML, hai spruzzato un po' di CSS e forse hai aggiunto un po' di JavaScript vaniglia se ti sentivi elegante quel giorno. Il browser ha fatto il suo dovere, e boom - avevi un sito web. Questo era tutto. Doveva essere - era tutto ciò che la tua connessione 56k poteva gestire.

Poi sono arrivati Internet ad alta velocità e V8: sono iniziati i framework, gli strumenti di compilazione, le librerie e gli infiniti livelli di astrazione. Da qualche parte nel vortice del raggruppamento, del transpiling e del polyfilling, Internet si è allontanato dalla sua semplicità originale e ha dimenticato quanto potessero essere potenti HTML, CSS e JavaScript vanilla.

Ma di recente, mentre lavoravo con Edge Delivery Services e Document Authoring di Adobe, ho sentito qualcosa di familiare, come l'iconico rumore della stretta di mano della connessione remota. EDS mi ha riportato alle radici del web: prima i contenuti, guidati dall'HTML, stilizzati dai CSS e veloci per impostazione predefinita.

Questo post parla di quella sensazione: ricordare come il web è stato pensato per essere costruito. Perché? Perché in un mondo di front-end gonfi e stack troppo complicati, la semplicità è più importante che mai.

Il primo web: diretto, onesto, veloce

C'era della bellezza nel modo in cui il web era semplice. Hai aperto un editor di testo, scritto un po' di HTML, aggiunto un po' di CSS in linea e, se avevi bisogno di interattività, forse hai inserito un tag script con un po' di JS vanilla. Questo era il flusso di lavoro. Nessuna fase di compilazione. Nessuna distribuzione. Nessuna dipendenza. Lo hai inviato via FTP a un server ed eri a posto.

Ha funzionato. È stato veloce. Chiunque poteva accedervi. Non si è rotto su macchine più lente né ha caricato 3 MB di JavaScript minimizzato solo per renderizzare un paragrafo. Potresti "visualizzare la fonte" e imparare effettivamente qualcosa. Era grezzo - quello che hai scritto è quello che è stato reso. Nessuna magia. Nessuna congettura.

Gli sviluppatori avevano il pieno controllo e la barriera all'ingresso era bassa. Non c'era bisogno di una laurea in informatica o di un corso in 20 parti sui metodi del ciclo di vita di un framework. Avevi solo bisogno di un browser, un editor di testo e un'idea.

Quando il Web è diventato grasso

Poi è arrivato il motore V8 di Chrome e, con esso, la moderna rinascita di JavaScript. Improvvisamente, JS non era solo un giocattolo. Era veloce, potente e ovunque. All'inizio sembrava una magia... ma in realtà, abbiamo appena aperto il vaso di Pandora.

Abbiamo iniziato a fare montagne con le talpe. Un sito che prima era composto da pochi file statici ora aveva bisogno di una pila di dipendenze, un bundler, un compilatore e metà della RAM solo per sputare fuori "Hello World". L'installazione di npm è diventata un rituale e non come la tua routine di cura della pelle. Più come evocare un demone che distrugge te e la tua build.

Abbiamo costruito strati su strati. Strumenti per gestire i nostri strumenti. Astrazioni per cose che non sono mai state complicate in primo luogo. Il mondo del front-end è diventato ossessionato dalle "app" invece che dai documenti. E da qualche parte nel caos, abbiamo perso di vista le basi: HTML per la struttura, CSS per lo stile e JS per il comportamento.

Entra in Adobe Document Authoring: solo contenuto

L'authoring di documenti di Adobe - onestamente? Una boccata d'aria fresca. A prima vista, sembra che tu stia solo modificando un documento di Word. Questo perché... Praticamente lo sei. È progettato per la collaborazione, è semplice da usare ed è facile da imparare. Basta pulire i contenuti a cui è facile per chiunque contribuire.

Quel documento che stai modificando non è semplicemente seduto da qualche parte in attesa di essere copiato e incollato in WordPress. Diventa la pagina. Quello che scrivi è ciò che viene consegnato al web: nessun caos headless, nessun markdown per reagire a JSON a qualcosa di pipeline.

È incentrato sui contenuti nel miglior modo possibile. Non c'è bisogno di ingegnerizzare il proprio modo di scrivere: si scrive e basta, e questo cambiamento da solo è enorme. Significa che si passa meno tempo a cercare di incollare i sistemi e più tempo a concentrarsi su ciò che conta davvero: il messaggio.

Che cos'è effettivamente l'EDS e perché funziona

Adobe Edge Delivery Services (o EDS, in breve; potresti averlo visto in giro come Project Helix o Adobe Franklin) sembra una rivoluzione silenziosa. Sulla carta, sembra quasi troppo semplice: il contenuto di un documento Adobe DA (o Word, o SharePoint, o Google Docs), strutturato con tabelle e intestazioni, poi consegnato al web utilizzando blocchi di JS e CSS vanilla. Nessuno strumento di compilazione. Nessun script di distribuzione. Nessuna integrazione CMS complessa. Basta scrivere, salvare e spedire.

E in qualche modo... Questo è il punto.

È il tipo di configurazione che ti fa fermare e chiedere: "Aspetta, perché abbiamo complicato tutto questo?"

Invece di trasformare tutto in un'app, EDS trasforma i documenti in siti web, nel modo in cui funzionava originariamente Internet.  Il documento si concentra sul contenuto. Se hai bisogno di layout o interattività, usi i blocchi. Ogni blocco è solo un pezzo di logica (Contenuto + CSS + JS) che sa come interpretare la struttura del documento e trasformarla in HTML pulito ed efficiente. Se riesci a leggere un documento Google e a ispezionare una tabella, puoi capire come funziona un blocco.

Ancora meglio, tutto il codice è open-source su GitHub, il flusso di lavoro di sviluppo è basato su Git e puoi vedere cosa sta facendo qualsiasi blocco in tempo reale con estensioni del browser come AEM Sidekick. È moderna in tutti i modi che contano, senza essere appesantita da tutte le cose che non contano.

Perché questo è davvero importante

Tutta questa semplicità non è solo nostalgica, ma pratica. Quando si elimina il rumore e ci si concentra sulla distribuzione di HTML reale con un po' di CSS e JS, tutto migliora.

I siti EDS sono veloci, come 100 punti Lighthouse, perché non c'è un framework JS gonfio che appesantisce le cose. Stai distribuendo HTML, non avviando un'app solo per mostrare l'immagine di un gatto.

Accessibilità e SEO? È lì dentro. Un HTML pulito significa che gli screen reader e i motori di ricerca comprendono effettivamente i tuoi contenuti. Niente trucchi, niente cerchi.

Esperienza di sviluppo? Ho abbandonato il college. Non stai litigando con le configurazioni o eseguendo il debug di una build non funzionante alle 2 del mattino perché un pacchetto in profondità nella catena è andato di traverso. Si costruisce un blocco. Lo stili. Tocchi l'erba.

Flusso di lavoro dei contenuti? Lasciateli cuocere. Gli autori e gli editor lavorano con strumenti che già conoscono (Google Docs, Word, SharePoint) e i loro aggiornamenti vengono pubblicati. Nessun gatekeeping. Nessun biglietto Jira per "puoi aggiungere uno spazio a quella frase?"

In breve: è più veloce da costruire, più facile da mantenere e più accessibile a tutti i soggetti coinvolti, dagli sviluppatori agli autori, agli utenti.

Ritorno al futuro

È facile pensare che il progresso significhi aggiungere più strumenti, più livelli, più astrazione. Ma a volte, la cosa migliore che puoi fare è spogliarti di tutto e ricordare cosa ha reso grande il web in primo luogo.

Adobe Document Authoring e EDS non solo semplificano le cose, ma le rendono anche più chiare. Danno di nuovo agli sviluppatori e ai creatori di contenuti un linguaggio comune. Ci ricordano che HTML, CSS e JS - solo le basi - sono ancora incredibilmente potenti.

Forse non si tratta di reinventare il web. Forse si tratta di togliersi di mezzo.

Vuoi approfondire i servizi di distribuzione edge?
Scopri come può trasformare la distribuzione dei tuoi contenuti consultando il nostro blog sull'authoring dei documenti per Edge Delivery o ascoltando la nostra discussione podcast su YouTube.

Informazioni sull'autore

Episodi di podcast e post del blog