Se analizziamo l’evoluzione tecnica del multimedia, spogliandola dal marketing e dalle sovrastrutture aziendali, ci troviamo di fronte a un gigantesco e costosissimo paradosso temporale. Abbiamo passato più di trent’anni ad ammassare strati di bloatware informatico, linguaggi intermedi, pesanti architetture del DOM e comitati standardizzatori, convinti che questa fosse l’unica via per l’evoluzione tecnologica.

E alla fine, dove siamo arrivati? Al fatto che, per ottenere vere prestazioni, il web odierno sta freneticamente strappando via i limiti dei tradizionali linguaggi di scripting. Stiamo letteralmente abbandonando il paradigma della “pagina” per ritornare a quel concetto originario di gestione grafica nativa, ipertestuale e immediata che l’architettura Amiga aveva già anticipato, compreso e dominato nei primi anni ’90, mentre il resto del mondo informatico arrancava nel buio.

Ecco l’anatomia di questo loop temporale durato trent’anni, smontato pezzo per pezzo.

L’era dell’authoring nativo: il controllo puro sui pixel

Tra la fine degli anni ’80 e l’inizio dei ’90, la concezione del multimedia su Amiga era pura avanguardia. L’hardware custom (Agnus, Denise, Paula) lavorava in parallelo, permettendo al software di aggirare i colli di bottiglia della CPU. In questo ecosistema sono nati strumenti di authoring assoluti come Cando o AmigaVision (il sistema a diagrammi di flusso sviluppato direttamente per Commodore).

Questi programmi permettevano di creare presentazioni interattive, ipertesti (i “link” prima che il web li rendesse mainstream), animazioni fluide e interfacce grafiche complesse. Era, a tutti gli effetti, il web moderno ma destrutturato e semplificato all’osso. Si usava la logica dell’Immediate Mode: il software comandava all’hardware di pulire e ridisegnare lo schermo fotogramma per fotogramma. Non c’era il concetto di una “pagina che scorre e si adatta alla finestra”. Lo schermo era una tela rigida su cui avevi il controllo assoluto di ogni singolo pixel, senza intermediari.

La prigione del testo e la pigrizia strutturale dell’html

Poi è arrivato internet, progettato non per fare grafica, ma per scambiarsi documenti accademici. Nascono l’HTML e il CSS. Questo introduce un paradigma radicalmente opposto: il Retained Mode (Modalità Conservativa).

Il server ti manda del testo, il browser crea un modello invisibile in memoria (il DOM) e calcola come impaginarlo. Il browser diventa strutturalmente pigro: se non muovi nulla, non ridisegna lo schermo. Ottimo per risparmiare risorse, ma devastante per il tempo reale grafico.

L’industria si è subito accorta che il web statico era una gabbia noiosa. Ma invece di ripensare il sistema, hanno passato quindici anni ad applicare toppe, forzando la riproduzione multimediale tramite plugin esterni pesantissimi, chiusi e insicuri (dai Java Applet fino a Flash). Era il caos: si cercava di far fare a un lettore di testi quello che un Amiga faceva nativamente trent’anni prima, ma con una frazione dell’efficienza.

L’oligopolio dei motori di rendering

Oggi quelle vecchie toppe sono estinte, e le regole su come si legge l’HTML, il CSS e JavaScript sono centralizzate. Ma a trasformare queste regole in pixel sono i motori di rendering. E qui c’è il vero collo di bottiglia del web moderno, diviso in tre grandi blocchi di potere:

• Blink (Google): Muove Chrome, Edge, Brave. È il monopolista assoluto, che impone i suoi standard e decide cosa deve passare e cosa no (come i tentativi di bloccare gli ad-blocker a livello di motore).
• WebKit (Apple): Muove Safari. Apple obbliga qualsiasi browser su iOS a usarlo, creando un recinto chiuso a doppia mandata.
• Gecko (Mozilla): Muove Firefox. L’unica vera barriera indipendente per evitare che il web diventi proprietà privata.

Anche se leggono lo stesso standard teorico, l’implementazione pratica del codice è diversa. I bug di calcolo degli spazi e l’esecuzione del JavaScript (affidata a interpreti diversi come il V8 di Google) rendono la perfetta compatibilità grafica un’illusione.

In questo scenario blindato, progetti folli e indipendenti come Ladybird (un quarto motore di rendering scritto da zero in C++ e Rust, in via di sviluppo nel 2026) sono ossigeno puro: rifiutano i codici delle multinazionali e dimostrano che si può ricostruire un sistema fuori dal monopolio.

Il ritorno alle origini: riprendersi lo schermo nudo

Oggi, dopo decenni spesi a cercare di strutturare i documenti testuali in scatole CSS, ci siamo resi conto che l’architettura a pagina non regge il peso delle applicazioni complesse. E la soluzione adottata dall’industria è stata, letteralmente, tornare al paradigma dell’Amiga utilizzando tecnologie iper-ottimizzate.

1. Il controllo della potenza (WebAssembly – Wasm) Non siamo più limitati al JavaScript impaginato. Wasm è un formato binario basato su una macchina astratta a stack. Permette di prendere codice nudo e crudo scritto in C, C++ o Rust e farlo girare dentro il browser a velocità quasi nativa, aggirando le inefficienze dell’interpretazione testuale.

2. Il controllo visivo assoluto (Canvas e WebGL) Il browser torna a fornirti una tela vuota. L’HTML si fa da parte. Con l’elemento <canvas> (2D) o accedendo direttamente alla scheda video tramite WebGL/WebGPU per il 3D, riprendi in mano il controllo dei vettori. Ridisegni geometrie e pixel fotogramma per fotogramma, sputando dati direttamente sulla GPU, esattamente come i chip custom Amiga bypassavano la CPU per manipolare la grafica.

3. La demolizione del DOM (Flutter Web) Il cerchio si chiude con framework come Flutter. Quando crei un’app per il web con Flutter, l’HTML viene totalmente ignorato. Il sistema usa WebAssembly per piazzare un motore grafico autonomo nel browser, che prende il controllo dell’intero schermo e ridisegna pulsanti, testi e animazioni a 60 o 120 FPS in purissimo Immediate Mode.

Ci sono voluti più di trent’anni e risorse incalcolabili per capire che il contenitore (il browser) andava svuotato. Per tornare a fare vera innovazione interattiva, l’unica strada logica era buttare giù le pareti dell’HTML e tornare all’essenza: un processore, un blitter virtuale, un canvas e il controllo diretto sui pixel.

Articoli – Marco Vaccaro