• chore: update javascript package dependencies #484
• feat: move from MathJax to Katex #483 👈
• fix: Mermaid and Math rendering in Jupyter Lab and VSCode #480
• fix: solara.server.jupyter.server_extension not activating #479 : 1 other dependent PR (#481 )
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @iisakkirotko and the rest of your teammates on Graphite

Please take a look at the merge conflicts, I guess it's that node typing line
What are the implications for bundle size? Is this an improvement?

And what are the top reasons for moving from mathjax to katex? I know @kolibril13 is a katex fan as well, maybe he also knows good reasons to switch.

katex got recommended to me by a friend, it's supposed to be fastest then mathjax.
https://katex.org/
I've never used it in a project before, so I cannot say much more about it.

The benefit of KaTeX is mainly package size, compared to MathJax, which we used previously. Looking at the unpackaged size of the two on npm, you can see that the size of mathjax-full, which we use now, is ~34MB, while the size of KaTeX is ~4MB.

As @kolibril13 said, KaTeX seems to be faster than MathJax, but I think in comparison to MathJax 3, the difference is pretty minimal. Note that Jupyter still uses MathJax 2, which is much slower.

Some people say that support for some LaTeX features in KaTeX might be lacking, but I don't foresee any of these being something that sees very frequent use in Solara apps. You can take a look at the KaTeX support table here