wasm would definitely be off the table here, payload would be much bigger, there are tons of security issues around getting it to run right with CSPs (and CORS concerns), the implementation of markdown.it is spectacularly fast and extensible allowing for tons of plugins and a huge existing ecosystem.
Just some more context on mini_racer. From day 0 at Discourse we insisted on a single pipeline to cook markdown, this completely eliminated a very nasty class of bugs I have experienced at Stack Overflow where server and client spoke slightly different dialects. For Discourse this is even more important cause plugins can amend the pipeline. For example:
is implemented in a plugin (parsing of [])
We have quite a few “quality of life” features we get by using unicorn and relying on forking, see:
Specifically we monitor and manage a sidekiq child process from the master process.
But… truffle has no GIL, puma is already in the Gemfile once we have mini_racer working, we could collaborate on memory conserving truffle setup that keeps sidekiq and puma in the same process. Or people could just spawn a sidekiq process by hand. Puma can certainly work, we make use of Rack.hijack extensively but that is implemented across Puma/Unicorn/Passenger already.