wasm はこの場合、明らかに現実的な選択肢ではありません。ペイロードが大幅に大きくなり、CSP（コンテンツセキュリティポリシー）や CORS の懸念を考慮して正しく実行させることに関するセキュリティ上の問題も多数あります。一方、markdown.it の実装は驚くほど高速で拡張性が高く、多数のプラグインと大規模な既存のエコシステムに対応しています。
mini_racer に関する追加のコンテキストを共有します。Discourse では最初から、マークダウンを処理する単一のパイプラインを堅持してきました。これにより、サーバーとクライアントがわずかに異なる方言を話していたために発生する非常に厄介なバグのクラスを完全に排除できました（これは私が Stack Overflow で経験した問題です）。Discourse においては、プラグインがパイプラインを変更できるため、このアプローチはさらに重要です。例えば：
はプラグイン（[] の解析）で実装されています
Unicorn を使用し、フォーク機能に依存することで得られる「生活の質（QoL）」を向上させる機能はいくつかあります。詳細は以下をご覧ください：
具体的には、マスタープロセスから Sidekiq の子プロセスを監視・管理しています。
ただし、Truffle には GIL（グローバルインタプリタロック）がありません。mini_racer が動作するようになれば Puma はすでに Gemfile に含まれるため、Sidekiq と Puma を同じプロセス内に維持し、メモリを節約する Truffle 設定について協力することも可能です。あるいは、ユーザーが手動で Sidekiq プロセスを起動することもできます。Puma はもちろん動作します。Rack.hijack を大規模に利用していますが、これは Puma、Unicorn、Passenger のいずれでも既に実装されています。