wasm sarebbe decisamente fuori discussione in questo caso: il payload sarebbe molto più grande, ci sono un sacco di problemi di sicurezza legati al suo corretto funzionamento con le CSP (e le preoccupazioni relative al CORS). L’implementazione di markdown.it è straordinariamente veloce ed estendibile, consentendo un’ampia gamma di plugin e un enorme ecosistema già esistente.
Solo un po’ di contesto su mini_racer. Fin dal primo giorno, a Discourse abbiamo insistito per avere un’unica pipeline per elaborare il markdown; questo ha eliminato completamente una classe molto insidiosa di bug che ho sperimentato su Stack Overflow, dove server e client parlavano dialetti leggermente diversi. Per Discourse questo è ancora più importante perché i plugin possono modificare la pipeline. Ad esempio:
è implementato in un plugin (analisi di [])
Abbiamo diverse funzionalità “di qualità della vita” che otteniamo usando Unicorn e affidandoci al forking, come si può vedere qui:
In particolare, monitoriamo e gestiamo un processo figlio di Sidekiq dal processo principale.
Ma… Truffle non ha GIL, Puma è già presente nel Gemfile non appena mini_racer funziona. Potremmo collaborare per creare una configurazione di Truffle che conservi la memoria mantenendo Sidekiq e Puma nello stesso processo. Oppure, le persone potrebbero semplicemente avviare un processo Sidekiq manualmente. Puma può certamente funzionare; facciamo ampio uso di Rack.hijack, ma questa funzionalità è già implementata in Puma, Unicorn e Passenger.