Hacker News new | past | comments | ask | show | jobs | submit login

Any software project should be lucky to have a post like this written by a user, let alone as wonderful a writer as Brian Hayes.

On comparison with KaTeX:

• It appears from this comparison page (https://www.intmath.com/cg5/katex-mathjax-comparison.php) that MathJax 3 is about twice as fast as MathJax 2, but still slower than KaTeX. (Though it's variable, e.g. by directly reloading https://www.intmath.com/cg5/katex-mathjax-comparison.php?pro... enough times, I was able sometimes to get load times for MathJax faster than some load times for KaTeX.)

• It is surprisingly difficult to get a clear answer to what exactly one gets in MathJax, in return for this slower speed. One relatively clear thing is that MathJax supports more features, e.g. last I tried something I considered basic was unavailable in KaTeX (IIRC it was adding a \label to an equation and referring to it again elsewhere in the page with \ref). But beyond that, if everything one needs happens to be supported by KaTeX, are there still reasons to use MathJax? One would imagine that someone on the MathJax team, or even a devoted user, would have such a list somewhere, but I haven't been able to find one.

• One thing I remember reading is that MathJax takes a fundamentally different approach, and that a lot of the time it spends is in measuring things on the page to get things exactly right, while KaTeX is looser about things. I do notice just now that on my mobile, where I have accessibility features turned on to zoom text to a larger default font size, with MathJax (on the above comparison page) all the equations are scaled up such that the font size of symbols in the page matches the font size of surrounding text, while KaTeX gets this wrong. What is the extent of such differences?

• Both MathJax and KaTeX support server-side rendering, and the speed differences vanish (for the reader at least) when nothing is being done client-side.

On MathML:

• Disclaimer: I must confess to an annoyance with MathML proponents because (1) they seem to advocate using MathML even though it has poor browser support. (Even in Firefox where it's supported the rendering is often poorer than TeX's), and (2) they seem to imagine (somewhat like the "semantic web" people) some ideal world where authors bother to indicate the semantics of their equations (e.g. what a \sum is a sum over) rather than simply communicate in notation. (Don't want to repeat comments; see this year-old thread: https://news.ycombinator.com/item?id=19347737 — in particular see the examples and comparison on the Wikipedia article https://en.wikipedia.org/w/index.php?title=MathML&oldid=9454... )

• MathJax does support MathML as an input format (for some tools I guess?), and support for MathML as output format is no longer built-in: see http://docs.mathjax.org/en/latest/output/mathml.html versus https://docs.mathjax.org/en/v2.7-latest/mathml.html Anyway, whatever the future of MathML (i.e. even if browsers someday care enough about “proper” mathematics typesetting to render it natively and like TeX), we'll still need something like MathJax or KaTeX running somewhere, as (La)TeX notation is what mathematicians are familiar with, and something like it is what they're likely to want to write.




I am a MathJax/KaTeX user, not developer, so some of what I say could be incorrect. I was under the impression that KaTeX does _no_ horizontal measurement to speak of, deferring it instead into CSS and styling calculations carried out by the browser. This is why at the moment KaTeX cannot write to a canvas / SVG representation, only to HTML. On the other hand, I think MathJax takes the more fundamental approach of knowing how to absolutely position every single glyph (although for HTML output, some of these absolute positions are perhaps replaced by more KaTeX-style rules).

This means that at the moment it would be fairly annoying to create a library which renders a commutative diagram such as [1] in KaTeX, as one would have to render each part of the diagram in the browser to calculate sizes, and only then compute positions for arrows - in particular this could only be done ahead-of-time by firing up some headless browser, taking measurements, and then hoping for the best (the client isn't using different font sizes, for example). MathJax seems more suitable for that application due to knowing the sizes of things.

[1]: https://en.wikipedia.org/wiki/Monoid_(category_theory)#/medi...


Ah that's interesting, thank you. Looks like an interesting design choice, and would explain how it manages to be so fast.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: