Avete presente quella sensazione di onnipotenza che provate quando il vostro codice passa tutti i test, il linter non urla e il build è finalmente verde?

Ecco, dimenticatela. Se usate i dispositivi Kobo, la realtà è molto più cruda e decisamente meno logica. Recentemente è emersa una storia che è un vero incubo per chiunque ami gli standard aperti e la pulizia del codice. Un autore ha pubblicato un nuovo eBook, tutto in regola, superando l’epubcheck con la grazia di un robot senza bug. Eppure, per i lettori Kobo, il file risultava ‘corrotto’.

Il colpevole? Non è un errore nel file, ma un pezzo di tecnologia fossile: il RMSDK di Adobe. Parliamo del motore di rendering che Kobo usa ancora oggi, una roba che sembra uscita da un setup retrocomputing degli anni 2010. È il cuore di Adobe Digital Editions, quel software che tutti usiamo solo perché dobbiamo, un monumento al DRM e alla pesantezza software.

Il problema è che questo motore è rimasto congelato nel tempo. Mentre noi ci divertiamo a usare CSS moderni, Flexbox, Grid e funzioni matematiche avanzate, il parser di Adobe si blocca non appena vede qualcosa che non appartiene al suo mondo preistorico. In questo caso specifico, una riga di CSS totalmente valida — una semplice funzione ‘min()’ per gestire la larghezza di un’immagine — è stata interpretata come un errore fatale. Il risultato? Nessun messaggio d’errore utile, solo un silenzioso e frustrante crash del file.

Da smanettone, trovo questa cosa assolutamente inaccettabile. Siamo nel 2026! Se un software non riesce a gestire un’istruzione CSS standard senza dichiarare il fallimento totale, non è un software, è un timer a scadenza che aspetta solo di esplodere. È il classico esempio di vendor lock-in mascherato da ‘compatibilità’: Kobo si aggrappa a un motore proprietario e vecchio di un decennio, e noi siamo costretti a scrivere codice ‘povero’ e antiquato solo per non far piangere il loro parser.

Per noi che amiamo smontare le cose e capire come funzionano, questo è un promemoria brutale: non potete fidarvi solo degli standard ufficiali se sotto il cofano c’è un motore che gira ancora a vapore. Se volete che le vostre creazioni (che siano eBook o script per una CNC) funzionino ovunque, dovete testarle contro il peggior scenario possibile. Dovete sottoporle al ‘tritacarne di Adobe’.

In conclusione: meno hype sui nuovi standard e più attenzione alla robustezza dell’implementazione. Finché le grandi corporation continueranno a preferire il controllo del DRM alla qualità dell’esperienza utente, saremo sempre costretti a scrivere codice come se fossimo ancora nel 2013. Una vera tristezza per chi ama l’innovazione.

Source: Your ePub Is fine

Preparate i caffè rinforzati e i manuali di troubleshooting, perché il mondo Node.js sta per diventare molto più burocratico.

Se pensavate che la vostra vita da sviluppatore fosse già abbastanza complicata tra bug di regressione e dipendenze che si romponi da sole, la notizia che arriva dal team di npm vi farà venire voglia di tornare ai bei vecchi tempi del C++ compilato a mano. Con l’arrivo della versione 12 di npm (prevista per luglio 2026), la filosofia del «scarica e spera che non succeda nulla di male» sta ufficialmente tramontando.

In parole povere: npm sta decidendo di smettere di fidarsi di chiunque. Il grosso della novità riguarda la sicurezza, ma per noi che amiamo smanettare con pacchetti di terze parti, le implicazioni sono pesanti. Il cambiamento principale è che l’opzione ‘allowScripts’ passerà di default su ‘off’. Cosa significa? Che i classici script di preinstall, install e postinstall — quelli che spesso servono a compilare moduli nativi con node-gyp o a configurare l’ambiente — non verranno più eseguiti automaticamente. Se un pacchetto ha bisogno di far girare del codice per installarsi correttamente, npm lo bloccherà finché non sarai tu a dirgli esplicitamente: «Ok, mi fido di questo tizio’.

E non finisce qui. Anche le dipendenze che arrivano direttamente da Git o da URL remoti (i famosi tarball) non verranno più risolte senza il tuo consenso esplicito tramite flag come ‘–allow-git’ o ‘–allow-remote’. In pratica, npm sta costruendo un vero e proprio checkpoint doganale per ogni singola dipendenza che entra nel tuo progetto.

Dal punto di vista della sicurezza, devo ammettere che è una mossa geniale. Chi non vorrebbe eliminare alla radice quella pratica sporca di far girare codice arbitrario al primo ‘npm install’? È una manovra che chiude falle enormi legate all’iniezione di codice malevolo tramite script nascosti. Se la guardiamo con l’occhio dell’hacker, è una difesa basata sul principio del ‘least privilege’ che fa la sua figura.

Però, parliamoci chiaro: per noi che amiamo costruire prototipi veloci, che scarichiamo librerie sperimentali per vedere se funzionano in un progetto Godot o che integriamo pezzi di codice presi dal web per una macchina CNC, questa è una seccatura monumentale. Il workflow diventerà più lento. Dovremo passare del tempo a revisionare i warning, usare ‘npm approve-scripts’ e aggiornare il nostro package.json con liste di permessi sempre più lunghe. È l’incubo di ogni maker: la fine della libertà creativa in favore di un ecosistema iper-controllato.

Il consiglio pratico? Non aspettate il 2026 per trovarvi in crisi. Se usate già npm 11.16.0 o versioni successive, iniziate a guardare i warning che appaiono durante l’installazione. Create la vostra whitelist ora, così quando arriverà il grande upgrade, l’unica cosa che dovrete fare sarà un commit e non una notte intera a cercare perché il modulo ‘sass’ non riesce più a compilare.

In definitiva: meno magia, più controllo. Un po’ come quando smonti un vecchio arcade e ti rendi conto che ogni singolo contatto deve essere pulito e testato, invece di sperare che la polvere non faccia corto circuito. Un po’ meno divertente, ma decisamente più sicuro.

Source: Upcoming breaking changes for npm v12

E se vi dicessi che il vostro tool di build preferito ha appena deciso di andare a vivere in un ufficio con aria condizionata e scritte motivational sulla parete?

Sì, è successo. VoidZero, il team di geni che sta rendendo il nostro ecosistema JavaScript meno frustrante grazie a vite, Vitest, Rolldown e tutta la suite, si è appena unito a Cloudflare. Per chi non mastica il linguaggio dei manager, significa che i creatori di questi strumenti ora fanno parte dell’ecosistema di uno dei giganti della rete.

Subito, però, scatta il riflesso pavloviano di ogni vero smanettone: «Ecco il solito acquisto per chiudere il cerchio e costringermi a usare solo i loro servizi». Il rischio di vendor lock-in è sempre dietro l’angolo, come un bug critico in produzione il venerdì pomeriggio alle 17:00. Se Cloudflare decidesse domani di rendere Vite un po’ troppo ‘ottimizzato’ per i propri edge worker, saremmo nei guai.

Però, restiamo calmi e non facciamo i soliti cinici da tastiera (anche se è la nostra specialità). Il comunicato ufficiale è, paradossalmente, piuttosto rassicurante. Il team ha dichiarato apertamente che Vite, Vitest, Rolldown e gli altri rimarranno open source, vendor-agnostic e guidati dalla community. In pratica, dicono che non cambierà nulla nel modo in cui scriviamo codice, ma che avranno più risorse per far volare tutto ancora più veloce.

E qui sta il punto: se Cloudflare mette i soldi e le infrastrutture per potenziare strumenti come Rolldown o Oxc, noi ne beneficiamo. Più velocità di compilazione significa meno tempo perso a guardare una barra di caricamento e più tempo per giocare con i nostri progetti in Godot o sistemare quel modello 3D su Blender che non ne vuole sapere di renderizzare correttamente. Se il risultato è un ecosistema più solido e performante, dire di no sarebbe un esercizio di puro nichilismo.

Cosa significa per noi che amiamo mettere le mani nel codice? Per ora, continuate a pushare come sempre. La sfida sarà monitorare come evolveranno le decisioni architettoniche. Finché la filosofia rimane ‘build anywhere’, possiamo goderti questo upgrade. Ma teniamo gli occhi aperti: se inizieremo a vedere troppi ‘Cloudflare-only features’ nascosti nei commit, allora la festa sarà finita.

In sintesi: un grande potenziale di crescita, ma non abbassiamo la guardia. Il software deve restare uno strumento, non un recinto proprietario.

Source: VoidZero Is Joining Cloudflare

Tirate fuori i fazzoletti, perché un vecchio amico sta per essere cancellato dal registro di sistema.

Se avete passato notti insonni a cercare di far girare engine pesanti o emulatori di vecchie console direttamente nel browser, sapete bene cosa significa asm.js. Era quel trucchetto, quel sottofondo di codice quasi-assembly, che permetteva di far fare al JavaScript robe che normalmente richiederedo un miracolo o un hardware da server farm. Ma SpiderMonkey ha deciso che è ora di fare pulizia e sta disabilitando le ottimizzazioni per asm.js.

Per chi non fosse nel giro, asm.js era un sottoset di JavaScript progettato per permettere performance quasi native. Non era WebAssembly (che è il vero re attuale, non neghiamolo), ma era una soluzione ‘artigianale’ geniale per spingere il motore JS oltre i suoi limiti teorici. Era un po’ come fare overclock a un processore usando i trucchi giusti: sporco, complicato, ma incredibilmente efficace.

Ora, tecnicamente, la notizia è logica. WebAssembly è qui, è standard, è pulito e non ha bisogno di quei workaround che rendono il motore di rendering un incubo di manutenzione. Dal punto di vista del team di sviluppo, mantenere quel codice legacy è come cercare di riparare una vecchia macchina CNC con i pezzi di un Commodore 64: puoi farlo, ma quanto tempo perdi prima di frustrarti?

Però, parliamoci chiaro, da smanettone c’è un retrogusto di nostalgia. Noi che amiamo smontare tutto, che passiamo il tempo tra script custom e progetti che sfidano le leggi della fisica del browser, siamo quelli che amano le ‘improprietà’ che funzionano. Vedere un’era che finisce ci ricorda che il progresso tecnologico è un rullo compressore che non si ferma davanti a nulla, nemmeno ai nostri piccoli trucchetti preferiti.

Cosa significa concretamente per noi? Se state ancora usando vecchi progetti basati su asm.js, preparatevi a vedere le performance scendere di brutto o, peggio, a vedere tutto smettere di funzionare. È il momento di fare il salto verso WebAssembly. Se state sviluppando qualcosa di serio, è il segnale che non potete più ignorare lo standard moderno. La tecnologia evolve, il ‘legacy’ diventa debito tecnico, e noi dobbiamo imparare a scrivere codice che non sia solo performante, ma anche compatibile con il futuro.

In breve: il browser sta diventando più pulito, più standardizzato e meno ‘wild west’. Un po’ meno divertente, un po’ più prevedibile. Ma ehi, almeno non dovremo più preoccuparci di quel codice bizzarro che sembrava scritto da un alieno sotto caffeina. Benvenuto nel mondo del web moderno, dove tutto è bello, ma forse un filo meno selvaggio.

Source: Saying goodbye to asm.js

Se pensavate che il browser fosse solo un posto dove far girare tab di Chrome pesanti come un mattone e controllare le notifiche di GitHub, preparatevi a riconsiderare i vostri pregiudizi.

C’è qualcosa di profondamente soddisfacente nel vedere algoritmi matematici trasformarsi in tramonti mozzafiato direttamente in una scheda web. Recentemente ho incappato in un post di Maxime Heckel che è una vera goduria per chiunque abbia passato troppe ore a combattere con i nodi di Blender o a scrivere shader che, invece di simulare la luce, simulano solo l’ansia da crash della scheda video. L’autore spiega come renderizzare cieli, tramonti e persino interi pianeti in tempo reale usando solo gli shader del browser.

Non stiamo parlando di semplici immagini statiche o di quei vecchi skybox sgranati che sembravano adesivi attaccati alla lente. Qui si parla di roba seria: raymarching, scattering di Rayleigh e di Mie, e persino l’assorbimento dell’ozono. In pratica, l’articolo sviscera come simulare fisicamente il modo in cui la luce interagisce con l’atmosfera. È quel tipo di matematica applicata che ti fa capire perché il cielo è blu e perché, quando il sole scende, tutto diventa arancione e drammatico, tipo un filtro Instagram ma con la dignità della fisica vera.

Per noi che amiamo smanettare con Godot o creare piccoli prototipi procedurali, questo è oro colato. La cosa figa non è solo il risultato estetico, ma la tecnica. Portare tutto questo nel web-graphics-stack significa che le barriere tra ‘web app’ e ‘motore grafico’ si stanno polverizzando. Se riesci a far girare un’atmosfera complessa tramite shader nel browser, significa che le potenzialità per i nostri progetti indie, i piccoli tool di visualizzazione o i prototipi di giochi procedurali sono praticamente infinite.

Ovviamente, non tutto è rose e fiori. C’è sempre il rischio che, tra un raymarching e l’altro, la ventola del portatile inizi a decollare come un drone della DJI. La sfida resta sempre la stessa: trovare l’equilibrio tra quel realismo che ti fa dire ‘wow’ e l’ottimizzazione che impedisce al browser di trasformare il tuo computer in una stufa elettrica. Ma ehi, se non rischiamo di bruciare qualche pixel, stiamo solo giocando con le figurine.

Se avete voglia di sporcarvi le mani con i calcoli e vedere come la luce si piega tra le particelle, andate a leggervi il post completo. È una lezione di grafica computazionale che non trovi nei manuali aziendali di default. Solo codice, matematica e zero fuffa marketing.

Source: Rendering the Sky, Sunsets, and Planets

Chi l’avrebbe mai detto che il futuro del runtime più veloce del momento sarebbe passato per il linguaggio che sta facendo impazzire tutti? Se pensavate che Bun fosse già abbastanza frenetico, preparatevi a un altro round di caffeina e compilazione pesante.

La notizia che sta facendo sgranare gli occhi (anche a me, mentre cercavo di far girare un vecchio script Python su un Raspberry Pi morente) è che l’esperimento di riscrivere Bun in Rust sta andando alla grande. I dati parlano chiaro: su Linux x64 con glibc, la compatibilità dei test ha toccato il 99.8%. In pratica, siamo a un passo dalla perfezione, o almeno dalla quota di errore accettabile per chiunque abbia mai provato a compilare un kernel custom senza piangere.

Per chi non fosse in tema, Bun è quel runtime che ha promesso di spaccare tutto, e l’idea di spostare la logica verso Rust non è solo una mossa per fare hype sui social. È una mossa tattica per portare la sicurezza della memoria e le performance di Rust nel cuore pulsante dell’ecosistema JS. Sapere che la compatibilità è così alta significa che non dovremo riscrivere i nostri script assurdi o le nostre automazioni per il riciclo di plastica solo perché il runtime ha deciso di cambiare filosofia.

Dal mio punto di vista, questo è il tipo di ‘hacking’ che amo. Non è la solita operazione di marketing di una big tech che vuole venderti un abbonamento SaaS mensile; è gente che prende un pezzo di software esistente e lo smonta pezzo per pezzo per ricostruirlo con materiali migliori. È come prendere un vecchio arcade anni ’80, svuotarlo della scheda originale e incastrarci dentro un FPGA moderno che emula tutto con una precisione atomica.

Cosa significa per noi che amiamo sporcarci le mani? Significa che lo stack tecnologico sta diventando ancora più potente e, paradossalmente, più accessibile. Se riesci a far girare un progetto su Bun, probabilmente sarà altrettanto fluido su qualsiasi macchina Linux che hai assemblato nel tuo garage. L’unico vero rischio? Che la velocità diventi così alta da farci sentire pigri. Se il codice gira istantaneamente, non avremo più scuse per non passare ore a ottimizzare quel loop inutile che abbiamo scritto alle tre di notte.

Insomma, tenete d’occhio questo progetto. Se quel 0.2% di incompatibilità dovesse svanire, potremmo trovarci davanti a un mostro di efficienza capace di far sembrare Node.js un vecchio Commodore 64 che cerca di far girare Doom. E onestamente? Non vedo l’ora di vedere quanto farà sudare la CPU.

Source: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

Avete presente quando cercate di spiegare a un neoassunto come funziona un circuito stampato e lui inizia a parlarvi di cloud computing e microservizi astratti? Ecco, l’intelligenza artificiale sta facendo esattamente la stessa cosa, ma con il web development.

Recentemente è emerso un pattern decisamente interessante che sta facendo discutendo su Hacker News: l’uso di Claude Code (e delle LLM in generale) per generare applicazioni funzionanti usando quasi esclusivamente HTML. Il concetto è quello della «unreasonable effectiveness of HTML». In pratica, invece di impazzire a configurare build system infiniti, Webpack che si rompe ogni due secondi o framework che richiedono tre giorni di setup solo per visualizzare un ‘Hello World’, si torna alle basi. L’AI è incredibilmente brava a manipolare la struttura semantica dell’HTML, rendendo il codice pulito, leggibile e, soprattutto, immediatamente eseguibile.

Per noi che passiamo le notti a smanettare con Godot o a modellare pezzi per le nostre CNC, questo è un promemoria fondamentale: la semplicità vince quasi sempre sulla complessità inutile. Spesso ci perdiamo in layer di astrazione che servono solo a far mangiare i grandi vendor di cloud, quando la soluzione più elegante è spesso quella che sta sotto i nostri occhi (e che i nostri vecchi Commodore potrebbero quasi masticare).

Cosa significa per noi maker e dev che amano il controllo? Significa che stiamo assistendo a un ritorno alla ‘democratizzazione del codice’. Se un’AI può generare un’interfaccia funzionale, interattiva e bella usando solo tag standard, il confine tra l’idea e il prototipo si è appena assottigliato di un chilometro. Possiamo creare dashboard per monitorare i nostri sensori Arduino o interfacce per le nostre stampanti 3D senza dover diventare esperti di React o Angular.

Certo, non è che l’HTML risolva tutto. Se dovete far girare un motore di gioco complesso, l’HTML da solo non basta (per fortuna, altrimenti avremmo tutti il browser al posto del cervello). Però, l’idea che l’AI possa ‘pensare’ in termini di strutture semantiche semplici è una bomba. È come tornare a usare un vecchio multimetro analogico: non ha le funzioni digitali fancy, ma quando devi capire se c’è tensione, è infallibile.

Meno fuffa, meno dependency hell, più struttura. Forse dovremmo imparare qualcosa da questo ritorno alle origini. In fondo, se una cosa funziona con l’HTML, perché complicarsi la vita con un framework che pesa 500MB?

Source: Using Claude Code: The unreasonable effectiveness of HTML

Immaginate di voler entrare in un club esclusivo e, invece di mostrare il pass, vi venga chiesto di scansionare un QR code con uno smartphone specifico, certificato e tracciabile, per dimostrare che non siete un bot. Sembra una gag di un film distopico, ma è esattamente quello che Google sta cercando di venderci con il nuovo «Google Cloud Fraud Defense«.

Per chi mastica un po’ di codice e segue le news del settore, il déjà vu è fortissimo. Nel 2023, Google ha tentato il colpo grosso con la proposta WEI (Web Environment Integrity), che voleva far certificare l’hardware del browser per evitare lo scraping. La comunità ha urlato allo scandalo (giustamente), parlando di DRM per il web e gabbie dorate, e Google si è ritirato con la grazia di un server che va in kernel panic. Ma non si sono arresi. Hanno solo cambiato packaging.

Il meccanismo è questo: trovi un challenge, scansioni un QR code col tuo smartphone e — boom — il sistema verifica tramite le API di Play Integrity che il tuo dispositivo è ‘legittimo’. E quando dico legittimo, intendo un dispositivo Android moderno con i Google Play Services installati. Se usi una custom ROM figa come GrapheneOS o LineageOS per proteggere la tua privacy, sei fuori dai giochi. Se usi Firefox per Android, sei un sospetto. È il classico caso di vendor lock-in travestito da sicurezza.

Ma veniamo alla parte tecnica, quella che ci fa venire voglia di smontare tutto. Come maker e hacker, sappiamo che non esiste un muro che un bot non possa scavalcare. Se un operatore di bot farm può comprare un Android da 30 dollari da Walmart e puntare una telecamera automatizzata su uno schermo, il sistema è già morto in partenza. È una soluzione che non risolve il problema alla radice, ma aggiunge solo uno strato di complessità e frustrazione per l’utente comune.

E poi c’è il vero problema, quello che non legge nei comunicati stampa pieni di hype: il tracking. Ogni volta che scansionate quel codice, state inviando a Google un segnale che dice: «Ehi, questo specifico hardware certificato ha appena visitato questo sito». È un sistema di attribuzione perfetto. Non è più solo difesa dalle frodi, è una rete di sorveglianza granulare che trasforma il vostro hardware in un identificatore persistente.

Per noi che amiamo l’open web, l’automazione trasparente e la libertà di far girare il software che vogliamo su hardware che abbiamo scelto noi, questa è una regressione. Esistono alternative come i sistemi basati su Proof-of-Work (tipo Private Captcha) che richiedono sforzo computazionale senza bisogno di sapere chi siamo o che telefono usiamo. Ma ehi, la privacy non vende abbonamenti Cloud, vero?

In breve: non fatevi incantare dal QR code colorato. Sotto la superficie c’è lo stesso vecchio tentativo di chiudere il web in un ecosistema certificato e tracciabile. Restiamo pronti a trovare il workaround, perché se c’è una cosa che sappiamo fare, è rompere le gabbie.

Source: Google Cloud Fraud Defence is just WEI repackaged

Se qualcuno vi proponesse di smontare il vostro motore preferito e affidare la gestione della combustione a un fornitore esterno che decide lui quando e quanto far girare i pistoni, probabilmente lo prendereste per il culo. Eppure, nel mondo del software moderno, lo stiamo facendo con una regolarità disarmante.

Il recente post di Tom MacWright su Val Town è un monito che scotta per tutti noi che amiamo avere il controllo. La storia è un classico: si parte con l’entusiasmo di usare Clerk per l’autoconsumazione dell’autenticazione (vabbè, per risparmiare tempo), si finisce in un labirinto di workaround, bug e, soprattutto, con il sito che va giù ogni volta che il fornitore ha un piccolo singhiozzo.

Il problema non è che Clerk sia ‘cattivo’ — anzi, hanno appena alzato 50 milioni di dollari e sono un successo clamoroso. Il problema è la filosofia alla base: l’idea di ‘eliminare la tabella utenti’ per affidarla interamente a un servizio terzo. Per noi che amiamo sporcarci le mani con database, tabelle e relazioni, questa è pura fuffa marketing che si scontra con la realtà dell’ingegneria.

Immaginate la scena: il vostro sistema è pronto, tutto fluido, ma l’SDK di Clerk vi colpisce con un rate limit di soli 5 request al secondo per l’intero account. Cinque. Praticamente come cercare di far passare un intero flusso di dati attraverso un tubicino per il caffè. E non finisce qui: quando Clerk va giù, il vostro sito non è solo ‘senza login’, è letteralmente inutilizzabile. È il classico single point of failure che ogni maker dovrebbe imparare a evitare dopo la prima volta che un modulo Arduino si brucia perché non avevi messo un diodo di protezione.

La buona notizia? Hanno finalmente tagliato i ponti e sono passati a Better Auth. È una scelta che trasuda sano approccio open-source: meno dipendenza cieca da un vendor, più controllo sulla gestione delle sessioni e, soprattutto, la possibilità di gestire i dati come si deve, senza dover sincronizzare webhook e tabelle come se stessimo facendo un puzzle impossibile.

Per noi che amiamo costruire sistemi che durino, la lezione è chiara: l’astrazione è fantastica finché non diventa una prigione. Se la vostra architettura non può sopravvivere senza un permesso esterno, non state costruendo un prodotto, state costruendo un castello di carte su un server di qualcun altro.

Quindi, la prossima volta che leggete un post che vi invita a ‘eliminare la vostra tabella utenti’, fate un bel respiro, controllate il vostro schema SQL e ricordatevi che il controllo è tutto. Preferite un po’ più di lavoro in più oggi, o un debugging disperato alle tre di notte perché un servizio third-party ha deciso di fare il capriccio?

Source: From Supabase to Clerk to Better Auth

Se c’è una cosa che mi fa sudare freddo da hacker, è quando un colosso come Google decide che sa come funziona la navigazione web. Siamo abituati a smontare le cose, a vedere il codice che c’è sotto il bel resto, ma a volte sembra che ci stiano mettendo delle cinghie per i polsi digitali.

L’ultima notizia è arrivata da Google Search: stanno rafforzando le policy anti-spam per un fenomeno che chiamano «back button hijacking». Spoiler: è una roba che fa impazzire chiunque abbia mai provato a fare un *tinkering* sul codice di un sito. In soldoni, si tratta di siti che interferiscono con il pulsante Indietro del tuo browser, rompendo l’aspettativa fondamentale dell’utente: clicchi Indietro e torni esattamente dove eri.

Il concetto è semplice, ma il dibattito è pesante. Questi siti, per qualche motivo (forse vogliono venderti un NFT che non ti serve, o magari vogliono che tu guardi una pubblicità su un argomento che non ti interessa), ti deviano la rotta. Invece di tornare alla pagina A, ti buttano sulla pagina B, o ti bombardano di raccomandazioni che non hai chiesto. Google dice che questo è un comportamento manipolatorio e, perciò, un’infrazione di «malicious practices».

E qui arrivo io, con la mia solita dose di cinismo da nerd. Naturalmente, quando sento parlare di «user experience» e «malicious practices» con quel tono quasi evangelico, mi viene da fare un colpo di tosse. È il classico *corporate-speak* che maschera un semplice desiderio di controllo algoritmico. Non è tanto che il pulsante Indietro sia magico, è che rappresenta la *libertà di errore* del web. Il bello di un sito, soprattutto per noi che amiamo fare esperimenti, è che a volte rompe, a volte ti porta fuori strada per un secondo, e va bene così. È il caos che ci ispira.

Per noi maker, hacker e sviluppatori, questo significa che il confine tra «interferenza utente» e «interazione creativa» si sta assottigliando pericolosamente. Siamo costretti a scrivere codice non solo per far funzionare un’idea, ma anche per dimostrare a un algoritmo che non stiamo manipolando l’utente. È un livello di *gatekeeping* che ci fa venire voglia di rispolverare il vecchio terminale e tornare al periodo d’oro del retrocomputing, quando l’unica cosa che contava era che il codice compilasse, punto.

Quindi, cosa fare? Per chi di noi sta lavorando a qualcosa di sperimentale, che magari sfrutta un *redirect* o un *event listener* un po’ più aggressivo per un effetto visivo o un *flow* narrativo complesso, preparatevi. Dovrete rivedere ogni singola linea di codice che tocca la navigazione utente. Non si tratta solo di pulizia tecnica, è un cambio di mentalità: il codice deve essere trasparente, prevedibile e, soprattutto, *non deve nasconderti nulla*.

In sintesi: il web si sta rendendo troppo ordinato. E se c’è una cosa che amo, è l’imprevedibilità. Ci vediamo nel *terminale*, dove le regole sono solo un suggerimento, non un decreto.

Source: A new spam policy for “back button hijacking”