Negli ultimi anni in molti hanno parlato di diverse politiche slow: slow food, slow life, ma forse nessuno ha mai parlato di slow web standard.

Fondamentalmente penso che ormai gli standard web siano veramente una cosa gigantesca, che se da un certo punto di vista permettono di costruire applicazioni sempre più complete e complesse, da un altro diventano estremamente difficili da seguire e introducono possibili rischi per la sicurezza e per la privacy.

Cominciai a scrivere per il web quando lo stato dell’arte erano HTML 4.01 e CSS 2.1 e ho assistito alla creazione dell’HTML 5 e di tante API che oggi gli sviluppatori danno per scontate e permettono di ottenere risultati un tempo ritenuti impossibili senza usare hack e/o javascript, da flexbox alle varie animazioni. Poi con gli anni un po’ ho perso la passione per lo sviluppo web, un po’ gli studi mi hanno assorbito il tempo, quindi non mi sono tenuto molto aggiornato.

Tuttavia, non è una mia impressione che le modifiche siano estremamente frequenti, infatti con HTML 5 hanno deciso di eliminare il numero e di trasformarlo in HTML Living standard una cosa che secondo me, anche sono anni che va avanti così, è sbagliata.

In qualsiasi ambito informatico c’è la tendenza a ricercare stabilità tramite rilasci a lungo termine, sia nell’Open Source (dalle release stable di Debian e i kernel Linux LTS a Firefox ESR) che nel software proprietario (uno su tutti è Windows che permette di rimandare gli aggiornamenti anche di mesi nelle edizioni Professional e Enterprise). Questo modo di fare di HTML va semplicemente nel verso opposto a tutti questi esempi.

In generale adoro i documenti che descrivono gli standard, siano RFC o altri tipi: solitamente sono documenti molto precisi, non ambigui, nonché l’arbitro di qualsiasi controversia, però spesso sono anche lunghi da leggere, quindi esistono diverse altre pubblicazioni che li dividono meglio, portano degli esempi etc. HTML in questo senso non è tanto diverso dagli altri, ma con aggiornamenti troppo frequenti è fin troppo facile creare incongruenze nel materiale derivato. E se, siti specializzati come MDN e simili riescono a stare dietro a tutti i cambiamenti, comunque per gli sviluppatori rimane difficile.

Questo problema è acuito dal fatto che, mentre solitamente gli standard hanno è uno storico delle revisioni, magari con un changelog dettagliato, lo sviluppo è collegato a una serie di repo su GitHub, tuttavia i file prodotti sono grandi e andare a sfogliare gli interi commit diventa veramente tedioso.

Per esempio l’altro giorno ho scoperto che i <link rel="archives" ...> sono diventati deprecati, ma sono ancora riportati in numerose pagine, anche in whatwg.org, e non sono riuscito a trovare né il motivo, né da quando lo siano diventati.

Infine, mi sembra che questa politica di continui aggiornamenti si scontri troppo con la realtà dei fatti: le persone semplicemente non tengono questo passo. Né gli utenti, che non possono aggiornare o in generale sono pigri, né certi sviluppatori, che continuranno ad usare certe tecnologie antiquate. Sia d’esempio il fatto che ancora non siamo riusciti a sbarazzarci completamente di flash e di certi plugin ActiveX (richiesti, per esempio, da dispositivi come certi DVR).

In passato vedevo il mio futuro come sviluppatore web professionista, ora sono abbastanza sicuro che sia una cosa che voglio evitare, sia per motivi come questo, sia per come sta evolvendo in generale il web development.