wasm definitivamente ficaria de fora aqui; o payload seria muito maior, há uma infinidade de problemas de segurança ao fazê-lo funcionar corretamente com CSPs (e preocupações com CORS). A implementação do markdown-it é espetacularmente rápida e extensível, permitindo uma infinidade de plugins e um enorme ecossistema existente.
Apenas mais um contexto sobre o mini_racer. Desde o dia 0 no Discourse, insistimos em um único pipeline para processar o markdown, o que eliminou completamente uma classe muito perigosa de bugs que experimentei no Stack Overflow, onde servidor e cliente falavam dialetos ligeiramente diferentes. Para o Discourse, isso é ainda mais importante porque plugins podem modificar o pipeline. Por exemplo:
é implementado em um plugin (análise de [])
Temos várias “melhorias na qualidade de vida” que obtemos ao usar o Unicorn e confiar no forking, veja:
Especificamente, monitoramos e gerenciamos um processo filho do Sidekiq a partir do processo mestre.
Mas… o Truffle não tem GIL, o Puma já está no Gemfile assim que o mini_racer estiver funcionando, poderíamos colaborar em uma configuração do Truffle que conserve memória, mantendo o Sidekiq e o Puma no mesmo processo. Ou as pessoas poderiam simplesmente iniciar um processo do Sidekiq manualmente. O Puma certamente pode funcionar; fazemos uso extensivo do Rack.hijack, mas isso já é implementado no Puma, Unicorn e Passenger.