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

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

Hai presente quella sensazione di quando stai smontando un vecchio Commodore 64 e ti accorgi che, nonostante i decenni, i circuiti tengono ancora? Ecco, succede qualcosa di simile nel mondo del runtime JavaScript, ma con meno polvere e più tipi sicuri.

Il team di Oven ha appena approvato una pull request che è una vera bomba: Bun viene riscritto in Rust. Sì, avete letto bene. Non è la solita manovra di marketing per attirare hype, ma un restyling profondo del core che punta a risolvere il vero incubo di chiunque scriva codice a basso livello: i memory leak e i bug di memoria che compaiono solo quando hai troppa fretta per andare a dormire.

Jarred Sumner, il volto dietro il progetto, ha confermato che la nuova versione passa tutti i test esistenti e, cosa che noi smanettoni amiamo, il binario è addirittura più piccolo di 3-8 MB. In un’epoca in cui le corporation ci propinano framework che pesano come un intero sistema operativo, vedere un runtime che si rimpicciolisce mentre si evolve è una boccata d’aria fresca.

Ma la vera notizia non è solo la dimensione. Il vero salto di qualità è l’introduzione dei tool del compilatore Rust per beccare i bug prima ancora che diventino un ticket su GitHub. Per chi è abituato a debuggare processi che crashano senza motivo apparente, passare a un ambiente dove il compilatore ti sbatte in faccia l’errore prima di lasciarti il binario è come passare dal saldare i circuiti a occhio nudo all’usare un microscopio elettronico.

Attenzione però: non è un rewrite totale che cambia le regole del gioco. L’architettura e le strutture dati rimangono sostanzialmente le stesse. Non aspettatevi un miracolo di performance infinito, ma piuttosto un sistema più solido, meno ‘flaky’ e molto più prevedibile. Il team sta ancora lavorando per eliminare le ultime ottimizzazioni necessarie prima del rilascio ufficiale, ma la versione canary è già disponibile per chi ha voglia di sporcarsi le mani.

Cosa significa per noi? Che potremo continuare a usare Bun per i nostri prototipi, i nostri server sperimentali o le nostre automazioni casalinghe con molta meno ansia da crash improvviso. Se siete pronti a testare questo nuovo capitolo, basta un comando: «bun upgrade –canary».

Io sono già qui che controllo se il mio ambiente di sviluppo esplode. Se vedete che il mio blog smette di rispondere, sapete chi incolpare.

Source: Rewrite Bun in Rust has been merged

Sai quella sensazione quando scarichi un pacchetto npm e ti dici: “Ma chi me lo fa fare di usare qualcosa che non ho scritto io”? Bene, ora hai un motivo in più per essere paranoico. Axios, il client HTTP più usato nel mondo JavaScript, è stato appena compromesso in modo elegante e subdolo.

La storia inizia con due versioni maligne (1.14.1 e 0.30.4) che sono state pubblicate su npm. L’attaccante ha preso il controllo dell’account di un maintainer e ha iniettato una dipendenza nascosta chiamata plain-crypto-js@4.2.1. Questa dipendenza non viene mai importata nel codice di axios, ma ha un solo scopo: eseguire uno script postinstall che scarica un Remote Access Trojan (RAT) cross-platform. Sì, avete capito bene: il tuo pacchetto preferito per le chiamate HTTP è diventato un cavallo di Troia.

Ma la cosa più inquietante? Dopo aver fatto il suo lavoro sporco, il malware si cancella e sostituisce il proprio package.json con una versione “pulita” per evitare di essere scoperto. Insomma, un lavoro da professionisti del crimine informatico.

Se pensavi che gli attacchi supply chain fossero roba da film, beh, ora è realtà. Questo attacco è stato così ben orchestrato che è stato rilevato solo grazie a strumenti avanzati come StepSecurity Harden-Runner, che ha notato connessioni sospette durante le build CI.

Per noi smanettoni, maker e hacker, questo è un promemoria importante: anche i pacchetti più affidabili possono essere compromessi. Ecco alcune lezioni pratiche:

1. **Sii paranoico**: Controlla sempre le dipendenze e usa strumenti come npm audit per rilevare vulnerabilità.

2. **Non fidarti, verifica**: Se vedi un pacchetto sospetto, ispeziona il codice prima di installarlo. Anche se è axios.

3. **Usa sandbox**: Se lavori su progetti importanti, considera l’uso di ambienti isolati per testare le dipendenze.

4. **Aggiorna con cautela**: Anche se un aggiornamento sembra legittimo, controlla sempre le note di rilascio e le firme delle versioni.

5. **Non sottovalutare il postinstall**: Gli script postinstall possono essere pericolosi. Leggi sempre cosa fanno prima di eseguirli.

La community di StepSecurity sta organizzando un webinar per spiegare meglio l’attacco e le contromisure. Se sei interessato, registrati pure. Ma nel frattempo, fate attenzione a cosa installate. Il mondo npm è pieno di insidie, e oggi abbiamo visto quanto possa essere pericoloso.

E ora, torniamo a smanettare con i nostri Raspberry Pi e Arduino, ma con un occhio di più sulle dipendenze. Stay safe, coders!

Source: Axios compromised on NPM – Malicious versions drop remote access trojan

Sai quante volte hai maledetto il sistema delle date in JavaScript? Se sei uno sviluppatore, probabilmente molte. Dopo quasi tre decenni di caos, finalmente abbiamo una soluzione degna: Temporal. Questa nuova API per la gestione del tempo in JavaScript è appena arrivata allo stadio finale di standardizzazione e promette di risparmiarci ore di debug e patchwork.

La storia di Temporal è un esempio perfetto di come la comunità open source possa risolvere problemi complessi con collaborazione. Nato dall’esigenza di superare i limiti dell’obsoleto oggetto Date, il progetto ha visto il contributo di aziende come Google, Microsoft, Mozilla e Bloomberg, oltre a tanti sviluppatori indipendenti. La cosa più sorprendente? L’implementazione è stata resa più efficiente grazie a una libreria condivisa in Rust, temporal_rs, che ha ridotto gli sforzi duplicati tra i vari motori JavaScript.

Ma cosa cambia nella pratica? Con Temporal possiamo finalmente lavorare con date e orari senza preoccuparci di problemi come il fuso orario, i bug del millennio o le incoerenze tra browser. L’API supporta addirittura la precisione al nanosecondo, un dettaglio che apre nuove possibilità per applicazioni scientifiche e di misurazione.

Per noi smanettoni, questa è una manna dal cielo. Finalmente potremo scrivere codice pulito e affidabile senza dover ricorrere a librerie esterne come moment.js o date-fns. Certo, ci vorrà un po’ di tempo per abituarsi alle nuove sintassi, ma il gioco vale la candela.

Ovviamente non tutto è perfetto. L’integrazione con le API web esistenti è ancora un lavoro in corso. Ad esempio, gli input di tipo ‘date’ o ‘time’ non supportano ancora Temporal nativamente. Ma con il tempo, anche questo problema sarà risolto.

In conclusione, Temporal è un passo gigante verso un JavaScript più moderno e potente. È una vittoria per tutta la comunità e un esempio di come la collaborazione possa portare a risultati straordinari. Ora possiamo finalmente dire addio agli orologi difettosi e guardare al futuro con ottimismo.

PS: Se ancora non hai provato Temporal, corri a fare un test su Firefox o Chrome. Ti stupirà quanto sia più semplice gestire le date ora!

Source: Temporal: The 9-year journey to fix time in JavaScript

Sapete quella sensazione quando apri un sito web e ti accorgi che sotto il cofano c’è ancora jQuery? Ecco, i suoi creatori evidentemente non vogliono che questa sensazione svanisca mai.

Con grande stupore (e un pizzico di sarcasmo), il team di jQuery ha annunciato la versione 4.0.0, un aggiornamento che promette di “rivoluzionare” il mondo del JavaScript. Ma dopo anni di oblio, è davvero il caso di festeggiare?

Per chi vive nelle grotte (o chi semplicemente ha smesso di usare jQuery nel 2015), ricapitoliamo: jQuery è quella libreria che ha reso il DOM gestibile in un’epoca in cui ogni browser aveva il suo modo di fare le cose. Oggi, con ES6 e moderni framework, sembra quasi un fossile. Eppure, eccolo qui, più vivo che mai.

La versione 4.0.0 introduce alcune novità interessanti: miglioramenti nelle performance, un sistema di plugin più flessibile e supporto ufficiale per i moderni browser. Ma la domanda che tutti gli smanettoni si pongono è: “Perché?”

Da un lato, è ammirevole che un progetto così datato continui a evolversi. Dall’altro, sembra quasi un atto di disperazione. In un mondo dominato da React, Vue e Angular, jQuery 4.0.0 è come vedere un Walkman in un negozio di cuffie wireless: tecnicamente funzionale, ma un po’ fuori luogo.

Per noi che amiamo smanettare, la notizia ha un significato pratico: se state ancora usando jQuery, forse è il momento di aggiornarsi. Se invece siete tra quelli che hanno abbandonato la nave, questa notizia vi farà solo sorridere. In entrambi i casi, una cosa è certa: jQuery non ha ancora detto la sua ultima parola.

E voi, userete jQuery 4.0.0? O preferite lasciarlo al passato come un vecchio disco rigido IDE?

Source: jQuery 4

Ok, dimenticate per un attimo le news sui metaversi e le blockchain inutili. C’è una cosa *seriamente* figa che è successa: un tizio, Fabien Sanglard, ha preso Street Fighter II, il gioco che ha fatto sognare intere generazioni di nerd (e consumato joystick), e l’ha reimplementato quasi da zero usando JavaScript. Non un porting, non un remake, ma una ricostruzione del codice originale, partendo dall’analisi del ROM.

Seriamente, pensateci un attimo. Questo non è “fare un giochino per divertimento”, questo è un livello di dedizione che fa piangere il creatore di Doom. Il progetto, chiamato “SF2 Warrior”, è una dimostrazione di reverse engineering pura, un omaggio all’architettura del gioco e una sfida tecnica mostruosa. Ha ricostruito i calcoli delle hitbox, la logica degli attacchi, l’IA dei personaggi… tutto.

E la cosa più bella? È open source! Quindi, se siete tra quelli che preferiscono smanettare con il codice piuttosto che giocare (o magari entrambi, non giudichiamo), potete scaricarlo, studiarlo, modificarlo, e persino aggiungere i vostri personaggi o mosse. Immaginate le possibilità: un M. Bison con un attacco speciale che invia un ping al vostro server, un Ryu che usa l’intelligenza artificiale per imparare il vostro stile di gioco… le combinazioni sono infinite.

Certo, non aspettatevi una grafica da Crysis. È volutamente minimalista, per concentrarsi sulla fedeltà del gameplay e sulla chiarezza del codice. Ma questo è un bene! Ci ricorda che la sostanza viene prima della forma, e che un buon gioco può essere divertente anche con grafica a 8-bit. Anzi, a volte *soprattutto* con grafica a 8-bit.

Unica nota stonata? Il sito è un po’ spartano. Ma hey, siamo qui per il codice, non per il web design, giusto? E poi, diciamocelo, chi si lamenta del web design quando c’è Street Fighter II ricostruito in JavaScript?

Link al progetto: [https://fabiensanglard.net/sf2_warrier/](https://fabiensanglard.net/sf2_warrier/)

Ora scusatemi, vado a scaricare il codice e a cercare di capire come far funzionare un Hadoken con un Raspberry Pi. E se qualcuno riesce a farci girare sopra Doom, mi faccia sapere.

Source: Street Fighter II, the World Warrier (2021)

WTF?! Qualcuno ha finalmente capito che non possiamo dipendere per sempre da servizi proprietari per ogni singola cazzata che vogliamo fare online?

Scherzi a parte, ragazzi, OpenWorkers è una cosa seria. In pratica, è una piattaforma self-hosted che ti permette di eseguire codice JavaScript (sì, proprio quello che ti fa venire l’orticaria quando trovi un punto e virgola mancante) in isolamento, proprio come i Cloudflare Workers. Ma la differenza fondamentale? Lo hosti tu, sul tuo server, con tutta la libertà e il controllo che ne derivano.

L’autore ha fatto un bel po’ di rodaggio: prima con vm2, poi con deno-core per due anni, e ora ha riscritto tutto in Rust usando `rusty_v8` (e con l’aiuto di Claude, che non so se è un altro AI o un tizio con la barba). E diciamocelo, usare Rust per queste cose è sempre una buona idea: performance, sicurezza, e la possibilità di dormire sonni tranquilli sapendo che non ci sono buchi ovunque.

Cosa puoi fare con OpenWorkers oggi? Fetch (ovviamente), KV store, binding per Postgres e S3/R2, scheduling di task con cron, e anche un po’ di crittografia con `crypto.subtle`. Insomma, roba utile per costruire API, microservizi, e tutte quelle cose che ci fanno impazzire.

La parte migliore? L’installazione è semplicissima: un singolo file `docker-compose` e un database Postgres, ed è tutto. Niente configurazioni complesse, niente trappole nascoste. Perfetto per chi, come noi, preferisce sporcarsi le mani piuttosto che cliccare su interfacce grafiche.

Ok, forse la cosa più interessante è che ti libera dal vendor lock-in. Cloudflare fa comodo, ma quando ti chiedono un rene per ogni singola richiesta, inizi a farti delle domande. Con OpenWorkers, sei tu a decidere le regole del gioco.

Certo, non aspettatevi la stessa scalabilità e affidabilità di un servizio gestito come Cloudflare. Ma ehi, siamo hacker, maker, nerd! Ci piace smanettare, ottimizzare, e trovare soluzioni creative. E poi, ammettiamolo, c’è qualcosa di intrinsecamente soddisfacente nel sapere che hai il controllo completo sulla tua infrastruttura.

Insomma, OpenWorkers è un progetto promettente che merita un’occhiata. E se siete dei maniaci del controllo come me, non esitate a provarlo. Magari poi ci raccontate cosa ne pensate e quali feature vorreste vedere implementate.

Ah, e se trovate un bug, ricordatevi di segnalarlo. Ma siate gentili, ok? Non siamo mica sadici!

Source: Show HN: OpenWorkers – Self-hosted Cloudflare workers in Rust