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