wasm definitivamente quedaría fuera de discusión aquí; la carga útil sería mucho más grande, hay un sinfín de problemas de seguridad relacionados con ejecutarlo correctamente con las políticas CSP (y preocupaciones sobre CORS). La implementación de markdown.it es espectacularmente rápida y extensible, lo que permite una gran cantidad de plugins y un ecosistema existente enorme.
Solo un poco más de contexto sobre mini_racer. Desde el día 0 en Discourse insistimos en tener un único pipeline para procesar el markdown; esto eliminó por completo una clase muy molesta de errores que experimenté en Stack Overflow, donde el servidor y el cliente hablaban dialectos ligeramente diferentes. Para Discourse esto es aún más importante porque los plugins pueden modificar el pipeline. Por ejemplo:
se implementa en un plugin (análisis de [])
Tenemos bastantes “mejoras de calidad de vida” que obtenemos al usar Unicorn y confiar en el forking, ver:
Específicamente, supervisamos y gestionamos un proceso hijo de Sidekiq desde el proceso principal.
Pero… Truffle no tiene GIL; Puma ya está en el Gemfile una vez que mini_racer funcione. Podríamos colaborar en una configuración de Truffle que conserve la memoria y mantenga Sidekiq y Puma en el mismo proceso. O la gente podría simplemente iniciar un proceso de Sidekiq manualmente. Puma definitivamente puede funcionar; hacemos un uso extensivo de Rack.hijack, pero eso ya está implementado en Puma, Unicorn y Passenger.