Un software legacy non deve per forza restare chiuso in un vecchio PC o dietro una sessione remota. Un progetto pubblicato il 31 ottobre 2026 mostra un Intel 486 completo che avvia FreeDOS direttamente nel browser: nessuna installazione sul dispositivo dell’utente e nessun server che esegue la macchina per ogni visita. La domanda utile per una PMI, però, non è se l’esperimento sia spettacolare. È capire quando conviene spostare l’esecuzione nel browser e quando è più solido mantenerla su una macchina virtuale server-side.
Il caso Retro486 cambia il punto di partenza
Tom’s Hardware ha provato Retro486, un emulatore ancora in versione 0.1 che riproduce nel browser un sistema Intel 80486DX2-66. Il progetto permette di configurare scheda madre, memoria, unità e schede di espansione, mentre lo stato viene conservato nel browser. FreeDOS si è avviato nel test della testata, anche se alcuni giochi hanno restituito errori: è un dettaglio importante, perché separa una demo promettente da una piattaforma già pronta per processi critici.
Il repository e486-web dichiara un’implementazione in JavaScript senza dipendenze runtime e documenta CPU, FPU, controller, storage e persistenza tramite IndexedDB e localStorage. Non è solo nostalgia. Dimostra che una parte di software storico, simulatori, configuratori e strumenti formativi può essere distribuita come applicazione web statica.
Il criterio: dove devono vivere calcolo e stato
Il confronto va fatto su quattro criteri: tempo di messa in opera, costo per sessione, controllo dei dati e comportamento quando gli utenti aumentano. L’emulazione client-side scarica codice e asset, poi usa CPU, memoria e storage del dispositivo. La virtualizzazione server-side esegue invece il sistema su un’infrastruttura controllata e invia al browser soltanto l’interfaccia o uno streaming della sessione.
Non esiste un vincitore assoluto. La scelta dipende da dove si trovano i dati autorevoli, da quanto è prevedibile il dispositivo dell’utente e da quali periferiche o servizi deve raggiungere il software legacy.
Browser: distribuzione semplice, ambiente variabile
Il vantaggio più concreto del browser è la distribuzione. Una build statica può stare dietro una CDN e partire da un link; il server non deve mantenere una macchina attiva per ogni visitatore. Per corsi, dimostrazioni, consultazione di archivi o configuratori offline, questo riduce l’attrito e isola ogni sessione sul dispositivo dell’utente.
Il prezzo è la variabilità. Potenza, memoria disponibile, policy del browser e dimensione dello schermo cambiano da un dispositivo all’altro. Un ciclo di emulazione pesante sul thread principale può anche bloccare l’interfaccia. La documentazione MDN sui Web Workers indica proprio i worker come soluzione per calcoli intensivi che non devono fermare la UI, ma aggiunge complessità a messaggistica, debugging e condivisione dello stato.
Anche la sicurezza non si esaurisce con la parola “sandbox”. Il browser limita molte capacità, ma file caricati, dati persistenti e API concesse dall’applicazione restano dentro il modello di rischio del sito. Lo stesso principio vale per gli agenti AI con accesso a strumenti: il confine tecnico aiuta solo se permessi e dati sono progettati in modo esplicito.
Server: più controllo, più costo operativo
La macchina virtuale server-side è preferibile quando servono un ambiente identico per tutti, backup centralizzati, log completi, integrazione con database interni o accesso a periferiche e protocolli non disponibili nel browser. È anche più semplice revocare una sessione e applicare una correzione una sola volta.
In cambio, ogni sessione consuma risorse centrali. Bisogna gestire autenticazione, isolamento tra utenti, capacità, patch, monitoraggio e ripristino. Se l’interfaccia viene trasmessa da remoto, latenza e connettività entrano nel percorso critico. Il server offre controllo, ma trasforma una pagina statica in un servizio da mantenere.
WordPress, automazioni e AI: non mettere tutto nel CMS
Su WordPress userei il CMS come livello editoriale e di accesso, non come runtime dell’emulatore. L’applicazione client-side può essere pubblicata su un dominio separato con una Content Security Policy precisa e incorporata solo dove serve. Se invece l’esecuzione è server-side, WordPress dovrebbe chiamare un servizio dedicato tramite API, senza conservare immagini disco, credenziali tecniche o processi lunghi nella richiesta PHP.
Le automazioni possono creare sessioni, applicare limiti e raccogliere eventi, ma devono distinguere lo stato effimero dall’archivio ufficiale. L’AI può aiutare a tradurre codice, generare test o documentare componenti; Retro486 attribuisce a Claude un contributo allo sviluppo. Non è una garanzia di correttezza. Il criterio resta quello di un workflow con controlli ed evaluator: comportamento osservabile, test ripetibili e revisione dei confini.
La scelta netta per una PMI
Per formazione, demo, consultazione e strumenti senza dati centrali sceglierei il browser: distribuzione più semplice e nessuna sessione server da dimensionare. Per gestionali legacy, processi con dati autorevoli, periferiche o obblighi di audit sceglierei il server. Se i due casi convivono, la soluzione migliore è ibrida: interfaccia e calcolo non sensibile nel browser, stato ufficiale e integrazioni dietro API controllate.
La take finale è questa: non portare un programma nel browser solo perché oggi è tecnicamente possibile. Fallo quando il dispositivo dell’utente può diventare parte affidabile dell’architettura. In tutti gli altri casi, la prevedibilità del server vale il costo operativo.