In mathup I included a second target to update the DOM directly .toDOM() and .updateDOM(oldMathNode) instead of .toString(). This would have been quite difficult if there wasn’t a nice mapping between the language and the DOM nodes. By implementing math in MathML browsers have made it easier for us software authors to write these other languages that serve different purpose then LaTeX. Our users benefit from this proliferation. Ultimately they don’t need to know which language is the native one, because all they write is:
<math-up>ln x = int_1^x 1/t dt</math-up>
And let the library translate to MathML for them.[1] https://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1....
> * Faster user experience, as the MathML code can be served directly and rendered by the browser (as opposed to parsed and rendered with the javascript engine).
Those two wouldn’t be there _if_, as the OP suggested, browsers would have supported a TeX-like way to render math instead of MathML.
\frac{1}{x}
How about now: <mfrac>
<mn>1</mn>
<mi>x</mi>
</mfrac>
MathML is a lot easier for library authors target and for web developers to work with, which makes it a superior choice as a native language to TeX.
* Less works for developers who no longer need to pick, integrate, and maintain a third party library for rendering.
* Faster user experience, as the MathML code can be served directly and rendered by the browser (as opposed to parsed and rendered with the javascript engine).
* More options. Maybe LaTeX is not the right choice of syntax (more people write math then professional mathematicians and PhD students). As translating to LaTeX is hard, translating to MathML is easier (I know, I’ve written one my self).