It's lovely when a website actually uses MathML on browsers that mostly support it (i.e. Firefox and IE with mathplayer).
<rant>
For those not convinced why MathML is preferable to javascript-polyfills:
i) Browser rendering of MathML is much faster than MathJax and even slightly faster than client-side KaTeX.
ii) It supports a wider range of mathematical notation that KaTeX. (This point is partially dubious since MathJax is slightly better than current implementations of MathML, in this regard, though that is a limitation of the implementations, rather than the spec itself, and is a consequence of the fact that almost all of the work has been done by volunteers, not full-time staff, even in the case of Firefox/gecko.)
iii) There isn't an ugly mess of spans within spans in the DOM (mainly aesthetic preference).
iv) One can easily copy the given formula and paste it into another application which supports MathML, such as Mathematica or Thunderbird.
Yes, you're right — I wasn't being sufficiently clear. MathJax is indeed a rendering system which takes an input format (TeX, AsciiMath, MathML and possibly others) and converts it into a chosen output format (HTML (with CSS) — effectively a hodge-podge of spans, SVG, or MathML — yes, MathML is both a possible input and output format).
Technologically, it makes sense to directly compare MathJax with native MathML rendering. For example, take a document containing MathML and compare how it renders in Chrome with MathJax enabled (where the MathML has to be converted into HTML, in order to be displayed) and in Firefox with MathJax disabled (so the MathML is directly rendered by the browser) — Firefox will be much faster.
From a social point of view, we can compare our world to one in which most browsers can competently render MathML. In the former, people creating webpages/writing comments on the web, containing maths, will, say, write some markdown with embedded LaTeX, and use a server-side processor which converts the markdown to HTML, leaves the LaTeX alone and includes the MathJax engine, so that the LaTeX can be rendered client-side. (Since they have to include MathJax anyway, they probably won't bother with the extra step of converting the LaTeX to MathML server-side. Hence, even browsers that could render MathML, will still need MathJax for the LaTeX.) In the latter world, the same person, writing the same document, would instead use a server-side processor converting both Markdown into HTML and LaTeX into MathML, and no longer needing to include MathJax. The complexity for the writer/publisher would be the same (or if you were using LateXML or TeX4ht, lower), but the experience of the reader would be much, much better.
The NIST DLMF is great, but it has some deficiencies for someone who does serious work with mathematical functions.
It was created with the print edition in mind, and the web edition as a companion, rather than the other way around. Due to this focus, a lot of the content is needlessly terse.
For example, a rather useful chapter on computer algebra methods for special functions (things like holonomic functions and Zeilberger's algorithm) was written for the DLMF, but had to be discarded (in my understanding) due to page constraints on the print edition.
Also, many useful formulas are missing, and very often a case is covered as "for z < 0, combine (13.7.6) with (12.1.2) and (12.1.15)" when actually combining those formulas is half the work and the purpose of a reference is to save me trouble (and avoid potential mistakes)!
Each chapter is also written by a different author, with slight differences in the way things are organized. The good thing is that it is more than just a database of facts, with the content presented in a way that makes mathematical sense, but it can also make it more difficult to simply look up a specific fact.
My biggest gripe is that some sections of the DLMF have a very cavalier attitude when it comes to complex variables and branch cuts. A fair number of "equations" are only correct when the functions are interpreted as multivalued, and the user needs to place branch cuts the correct way. This really sucks if you need to do actual computations.
In quite a few places of the DLMF, no information about complex variables is given at all even though these are important in practice.
I often use the Wolfram Functions site (http://functions.wolfram.com/) as a complement to the DLMF, and the contrast in approach is very interesting.
The WF site is much more of a database, containing lots of more or less automatically generated entries. It is generally much more comprehensive than the DLMF, in that it allows you to look up variations and special cases of a formula in explicit form. On the other hand, it lacks most of the context and explanations provided in the DLMF.
Since the WF site content is organized completely systematically, it is very easy to find a specific formula and to compare analogous entries for different mathematical functions.
On the other hand, the WF content is harder to navigate unless you're already familiar with it. The tables of automatically generated formulas also contain a fair number of "junk" entries that no human would ever find useful.
The WF site is completely explicit about branch cuts (which makes sense since the Mathematica designers care about actual computations).
I have found some errors in the WF site, but they are quite rare. The Wolfram people actually use numerical "unit tests" for the formulas (checking identities numerically for carefully chosen values of the variables in order to verify correct use of branch cuts etc).
One of the Mathematica developers responsible for the WF site was actually present at a DLMF development meeting which took place in connection with a conference at NIST a couple of years ago, and he gave the DLMF editors a bit of a scolding about the branch cut issue, but not much happened. There's a bit of difference in philosophy: viewing a special function as a more abstract thing vs fixing concrete branch cuts.
A third interesting approach to a special functions resource is the Dynamic Dictionary of Mathematical Functions (http://ddmf.msr-inria.inria.fr/1.9.1/ddmf) which is even more automated than the WF site.
In the DDMF, a function is defined by a differential or difference equation, and all theorems and formulas are essentially generated algorithmically from first principles! Very neat. But the content that can be generated automatically this way is still quite limited compared to completely human-curated resources.
This is pretty cool, especially the physical applications sections. And it brought back some memories from various physics classes on the enigmatic questions that lead to the development and understanding for some of these functions. See the Bessel Function, http://dlmf.nist.gov/10.73: "Bessel functions first appear in the investigation of a physical problem in Daniel Bernoulli’s analysis of the small oscillations of a uniform heavy flexible chain."
Not directly, but this is very nearly a web version of the Handbook of Mathematical Functions by Abramowitz and Stegun [1]. There is a pdf of this book (at the link).
<rant>
For those not convinced why MathML is preferable to javascript-polyfills:
i) Browser rendering of MathML is much faster than MathJax and even slightly faster than client-side KaTeX.
ii) It supports a wider range of mathematical notation that KaTeX. (This point is partially dubious since MathJax is slightly better than current implementations of MathML, in this regard, though that is a limitation of the implementations, rather than the spec itself, and is a consequence of the fact that almost all of the work has been done by volunteers, not full-time staff, even in the case of Firefox/gecko.)
iii) There isn't an ugly mess of spans within spans in the DOM (mainly aesthetic preference).
iv) One can easily copy the given formula and paste it into another application which supports MathML, such as Mathematica or Thunderbird.
v) It can be easily embedded into svg and webgl, resulting in pretty diagrams or graphs. For example see http://fred-wang.github.io/MathUI2014/demos/2-mathml-in-svg.... or http://fred-wang.github.io/MathUI2014/demos/6-mathml-in-webg... .
vi) Javascript can easily interact with MathML, without worries about order of execution etc.
vii) It's a web standard :p
Obviously, it's great that MathJax and KaTeX exist, but it would be even better if they didn't _have to_.
</rant>