My point is that "fast" in those kinds of workarounds wouldn't be a problem for visitors of a site because all the browser gets is just native MathML.
You can do this server side or client side and sadly too many people do it client side. If you do it server side, it is just one more step in your build next to transpiling and bundling.
The key issue is that the latex stack wasn't really designed to be packaged up like this. It just has a lot of moving parts that are vaguely dependent on running in a full blown unix like shell environment. So the resulting code would be a rather big blob. Running that in a browser isn't that hard if you can live with that having a fair bit of overhead. This has been done. But it's a bit overkill for publishing content on the web.
Browsers don't have native support for MathML any more for a good reason. Mozilla did support this for a while but dropped it because of limited adoption and high maintenance burden. Rendering formulas is a bit of a niche problem and the intended audience is just kind of picky when it comes to technology and generally not that into doing more advanced things with web browsers. Also, most people writing scientific articles would be writing those for publication and probably use Latex any way. So translating all their formulas to MathML is an extra step that they don't need or want.
At least that's my analysis of this. I'm not really part of the target audience here and I'm sure there are plenty of MathML fans who disagree with this.
In any case Katex makes an acceptable (to some) compromise by packaging this stuff up in a form where it can be run server side and is easy to integrate on a simple web page. A proper solution with buy-in from the scientific community (for e.g. MathML) is a much bigger/harder thing to solve.
IMHO, a light weight solution based on web assembly could be the way to go. But of course the devil is in the details because if the requirements are "do whatever latex does" it gets quite hard. And anything else might be too limited.
This seems to just be entirely untrue? https://developer.mozilla.org/en-US/docs/Web/MathML shows wide support (For Chromium/Blink-based since version 109) and if I open the example https://developer.mozilla.org/en-US/docs/Web/MathML/Guides/P... in Firefox and Edge both seem to render it correctly.
The big issue is that MathML is designed as a target language, not something directly writable. So we still need a KaTeX equivalent, which compiles either LaTeX equations or other markup languages to MathML.
Regardless, the core issue that you have mentioned is now gone (or will be in a few years even if you want more availability).
Even if we address this problem using custom web fonts, there are numerous other edge cases (spacing within subscripts and superscripts, sizing within subscripts within subscripts, etc.) that look odd in MathML. At that point, we might as well use full KaTeX. Granted, many of these issues are minor. If they don't bother you, MathML could be a good alternative. Unfortunately, for me, these inconsistencies do bother me, so I've been using MathJax, and more recently KaTeX, since they get you closer to the typesetting quality of LaTeX compared to MathML.
Indeed! That was precisely the point of my comment.
I agree that switching to Latin Modern could resolve some of the minor issues I mentioned earlier. However, I'm not sure it will address all of them: particularly the spacing inconsistencies within subscripts or nested subscripts. Still, it's definitely worth experimenting with and I will if I can find the time. But I agree that simply using Latin Modern would make a lot of difference.
However, my goal isn't to replicate LaTeX's spacing behavior faithfully. I just want the rendered formulas to look good, close to what I find in print or LaTeX output, even if it's a bit different. It so happens that I find myself bothered by some of the spacing decisions in edge cases when using MathML (and I haven't checked whether changing fonts would fix that), so I tend to just stick with MathJax or KaTeX. But that's just me. I don't mean to say one is better and the other is worse. If MathML output looks good to others with certain fonts, that's a perfectly valid reason to use it. I might even switch to it myself if I can arrive at a setup that produces results I'm happy with.
This website has a comparison of the loading times of the same LaTeX rendered in both KaTeX and MathJax: https://www.intmath.com/cg5/katex-mathjax-comparison.php
Most critique of KaTeX over MathJax is reduced support for LaTeX features.
The costliest asset is a minified stylesheet served through a CDN. (I do this out of laziness, and because the web app as-is needs nothing more than the standard Rust toolchain).
The docs recommend setting up KaTeX CSS (which requires either a CDN link or Node), but by changing output to 'mathml,' you can have the browser render equations with zero dependencies.
Disclaimer: I am the author of PyKaTeX.
I’m sure engineers working on products like the google web suite would love to implement this kind of thing but have zero authorization or resources for that.
Experimental applications, the ones that bloom rapidly and get shut down in a cycle that google has become known for, are ironically way more likely to see this kind of cool niche update.
Twisted company has a whacky way of managing their products, because advertisement drives their revenue so everything else is just freestyle jazz.
I have a javascript hack from the dev console where I can at least print the chat to PDF, https://andrewpwheeler.com/2025/08/28/deep-research-and-open... (that at least worked 2 months ago)
But with the development of Typst, maybe the way to go is to use Typst rather than Markdown.
The only feature I really missed was the ability to use \label and \eqref for equation referencing, since KaTeX doesn't support these commands [1]. I worked around this limitation with a small custom setup defining my own \label and a custom \eqnref (not exactly \eqref though) [2].
Another thing that bothered me a little was that the KaTeX autorender extension does not recognise \begin{align*}, \begin{alignat*}, etc. as top-level delimiters by default [3] but this was trivial to fix by customising the set of default delimiters [2].
I know KaTeX supports server-side rendering but I don't use that yet [4]. I still use client-side rendering. Despite that my maths pages [5][6] render quickly since they are usually small, with only a single reflow from the initial load to the rendered page, without the continual reflows or jitter I used to see with MathJax. Overall, I am quite happy with the switch from MathJax to KaTeX.
[1] https://katex.org/docs/supported.html
[2] https://github.com/susam/susam.net/blob/0.3.0/layout/include...
[3] https://katex.org/docs/autorender#api
[4] https://news.ycombinator.com/item?id=44615271
https://docs.getoutline.com/s/guide/doc/formatting-kn6wBtxlQ...
The idea is similar to https://betterexplained.com/articles/colorized-math-equation..., but with mouseover interaction (both for further description, but also for accessibility). For a deeper dive in the topic of explorable explanations, I wrote https://p.migdal.pl/blog/2024/05/science-games-explorable-ex... (was here on the HN as well).
suioir•5d ago
[0] https://news.ycombinator.com/item?id=45701400
joppy•6h ago
djoldman•5h ago
Galanwe•5h ago
Latitude7973•5h ago
cubefox•3h ago
Vosporos•5h ago
ayhanfuat•4h ago
blenderob•3h ago
What a boldly incorrect comment! It's like you didn't even read the first point in TFA!
lifthrasiir•5h ago
susam•2h ago
Quoting the relevant part from that link:
Of course, if the page uses more symbols in various sizes, then a few more fonts files (.woff2) need to be pulled in which case the weight of KaTeX would increase a bit too. Each font file weighs between 4 kB and 28 kB.adastra22•4h ago