This article should not be taken seriously, which has at least 2 fatal errors in its argument.

First about the choice of delimiter. It argues for the use of \(…\) and \[…\] instead of $…$ and $$…$$. They don’t even explain why, but cite an external link to, guess what, a reason why the former is better for LaTeX, not markdown.

Then they made a claim about why putting math inside code delimiters are better.

Detouring a little bit, my guess that GitHub chooses this delimiter is because they have prior collaboration with the author of pandoc to create the common mark spec. Their GFM parser is an extension of a common mark parser.

And since pandoc chooses the dollar sign delimiter as the math delimiter, it is natural for them to choose it too, just to have lesser variants.

Then why pandoc choose $ instead of \(…\) and \[…\]? And would that goes against the best practice of LaTeX?

The answer to the latter question is no, because the $ is the markdown delimiter, and when transpiled to LaTeX, it becomes the \(…\) and \[…\].

Answer to the first question is related to the fact that at least in pandoc, \[ means escaping the [. So to type \[ in markdown, it should be \\[, which is cumbersome. (There’s a special flag in pandoc that you can use bare \(…\) and \[…\] though.)

And since all this parsing is happening at the parser level, the code-delimiter argument is invalid. They are thinking more in terms of hacking an existing parser and render math as a post-processing step.

The second fatal error is comparing MathJax to KaTeX by showing the commit freq. and claim that MathJax is dead.

This is a really amateurish argument seen occasionally elsewhere in the open source community that if a software has no recent commit history it is dead.

In this particular instance, KaTeX is far behind MathJax in terms of coverage of rendering valid LaTeX math. This alone means they have a lot of catch up to do and no wonder a less mature software has more commit activity than a more mature one.

MathJax is backed by a lot of organizations/universities and they have commitment to maintain it. It is far from being dead.

KaTeX aims at being fast (MathJax 3 reclaim that territory a bit but AFAIK KaTeX is still king in that aspect.) If the math you use can be rendered by KaTeX, then use it. But it happened to me that I have to change a config to use MathJax instead of KaTeX because soon or later I’m going to use something KaTeX doesn’t support.

As GitHub doesn’t give you choice, choosing a default that has better coverage is no brainer.