wasm в данном случае точно не подойдёт: размер полезной нагрузки был бы намного больше, возникло бы множество проблем с безопасностью при корректном запуске с учётом CSP (а также опасений по поводу CORS). Реализация markdown-it невероятно быстрая и расширяемая, что позволяет использовать множество плагинов и опирается на огромную существующую экосистему.
Вот ещё немного контекста о mini_racer. С самого начала работы над Discourse мы настаивали на едином конвейере для обработки markdown, что полностью устранило целый класс неприятных багов, с которыми я сталкивался в Stack Overflow, когда сервер и клиент использовали слегка разные диалекты. Для Discourse это ещё важнее, поскольку плагины могут модифицировать конвейер. Например:
реализуется в плагине (парсинг [])
Используя Unicorn и полагаясь на механизмы fork, мы получаем ряд «удобств для пользователя». Подробнее об этом можно прочитать здесь:
В частности, мы отслеживаем и управляем дочерним процессом Sidekiq из главного процесса.
Однако… в Truffle нет GIL, Puma уже присутствует в Gemfile после того, как mini_racer заработает. Мы могли бы совместно поработать над настройкой Truffle, экономящей память, при которой Sidekiq и Puma находились бы в одном процессе. Или же люди могли бы просто запустить процесс Sidekiq вручную. Puma определённо может работать; мы активно используем Rack.hijack, но эта функциональность уже реализована для Puma, Unicorn и Passenger.