[klodolph]

It's more of a macro system stapled to a layout engine, which emits a DOM tree.

WebAssembly sucks at DOM. It sucks huge. WebAssembly can't hold a reference to a DOM object and can't even create strings. You have to do that all in JavaScript, and then import that JavaScript code into your WebAssembly module. You'll end up doing something weird like sticking your DOM objects in an array and then passing indexes into the array to your WASM code. Strings have to be encoded/decoded to get them in/out of WASM.

MathJax is written in TypeScript. If you want WASM, that means rewriting large parts of MathJAX, keeping other parts in JS, bridging them, and dealing with all of the resource dependencies (i.e. dealing with WebPack).

And anyway, JavaScript is decent at string processing.

[elcritch]

Good points! It doesn't seem like it'd help unless there's a really compute expensive portion. I doubt any parsing would be a limiting factor.

[klodolph]

Most people don’t think parsing is the limiting factor—which is why we’re always surprised when we measure and it ends up being the slowest part of the process (not common, but it does happen)

It would be interesting to know what the slowest parts of MathJax are.