I use MathJax for rendering equations on https://ultimateelectronicsbook.com/ and it's worked very well from a rendering quality perspective. I looked at Katex for performance, but it didn't support all of the LaTeX formatting that I use.
You can scroll through https://ultimateelectronicsbook.com/systems-of-equations/ for a particularly formatting-heavy example with lots of matrix equations and augmented matrices, working through Gaussian decomposition and LU factorization examples.
Instead, for performance, I wrote a small Ruby / Jekyll plugin to do MathJax server-side rendering. It calls the mathjax-node npm package, with some caching on top because it's so slow. This outputs static HTML and CSS with a few math fonts.
The mathjax-node-sre npm package even populates aria-label fields for each equation:
<span class="mjx-math" aria-label="y left-parenthesis x right-parenthesis equals StartFraction 1 Over 1 plus x EndFraction">...</span>
If you have the option to consider server-side equation rendering, your users may thank you.
> If you have the option to consider server-side equation rendering, your users may thank you.
I'm developing KeenWrite[0], a desktop-based text editor that provides real-time rendering of TeX. It has two TeX-related HTML export formats: SVG (no rendering for either client or server) or TeX (requires client-side rendering). Behind the scenes it uses a highly-optimized version of JMathTeX[1] that includes a custom renderer to handle translating math font glyphs into SVG paths.
I hooked up something similar when I was writing "julia as a cli calculator" [1], but it uses real TeX behind the scene, which gives me the opportunity to utilize existing TeX ecosystem such as TikZ and typography. Accessibility can be a problem, but I think it's possible to include some hints via the title attributes with some work.
I hope to see more server-side solutions. The customizability and client-side overhead (you only need to render once on the server, possibly with caching) is not something a client-side library can achieve.
Slightly off-topic, but I really like the layout and feel of your website. I find the fonts and colours to be quite pleasing, and the site loads incredibly quickly.
Thanks! I am not a designer so that's accidental -- and much credit is probably due to the default Jekyll theme (https://github.com/jekyll/minima). But performance optimization is something I enjoy and something I do as a break from writing the actual content.
If you are at all concerned with performance and can sacrifice a couple features (fewer supported text formatting options & mathematical elements, less legacy support for some browsers). Katex is a great alternative.
My android phone gets ~2700ms for KaTeX, ~3100ms for MathJax 3, ~17000ms for MathJax 2.7. There were times KaTeX and MathJax traded which I'm guessing is due to page size differences and my poor Internet connection.
MathJax can do synchronous also, but it's a config option. The fact that it defaults to async really saddles it with the perception that it's incredibly slow. The async operation basically forces the browser to through many, many rounds of relayout, when in most cases it would be much more efficient to do it in one batch.
I don't track that, but based on last time when I broke the fallback... it is important to have the fallback. There are cases where MathJax can handle input that is technically not valid in modern latex, and the katex devs explicitly decide not to support that input. My users don't care and have lots of content that works in mathjax only, so I have to support it (since Jupyter compatibility is important, and Jupyter uses mathjax).
I you want to quickly write some math to your website without necessarily knowing latex, then I wrote a tool called MathUp[1] which takes quick to write and easy to read math expressions and translates them to native MathML. MathJax can take native MathML as an input so you can feed it to MathJax to render it beautifully.
I found the documentation hard to follow to get server rendering to work, so here’s an example of MathJax integrated with marked [1], and an example of it in action [2] (scroll down).
I’m amazed at how well MathJax works in CodiMD/HedgeDoc, not just math, but importing and using eg. chemical equation support (`$\require{mhchem}$`) as well. Kudos.
I used to use Mathematica or MatLab to export image files of equations or matrices, and embed those images into my papers. I would already have those equations loaded into the software as part of the research, so it really wasn't any extra work, and ensured they were copied over as they were actually used. Why is so much time spent trying to get complex math rendering added to text editors, especially when math research may define new renderings?
Accessibility. Your nice images are someone blind's nightmare when the most important parts of a stem web page or pdf are actually just an empty alt tag.
I really hate to engage further on this as no one seems receptive, but, believe me... accessibility was a must as NSF grants through the university were involved. LaTex and illegible raw ASCII were also embedded in the PDF.
There were other diagrams and charts and graphs, but at some point, no text editor could process and render everything natively, or be fully accessible to every disability.
That's why standards. Partial implementations are always a best attempt at something and having it in a uniform way makes it easier for everyone.
NSF grands are only part of the picture. Knowledge is dispersed among arxive.org papers, pdf textbooks and random blog articles with each of them doing different thing and very often this thing is just slap an image of the formula and go on.
How do you standardize new mathematical expressions that haven't been invented/discovered yet? How do you deal with fundamental disagreements surrounding those standards? Politics and Capitalism creep in everywhere, and pretending that a "uniform way" will present itself is childish.
I think that you are missing the point. A standard must not dictate which symbols should be used, if it is a straight arrow, curved arrow, or a dotted one. Its purpose is to allow all kinds of symbols, positioning and denoting of relationships so that all symbols, relationships and positioning could be reproduced from the consumer of the data, be it a browser or a screen reader.
What you do might be nice, but it does not scale. People do not include stuff for accessibility's sake. Web is the ultimate proof of that. That's why I prefer if accessibility is included in the workflow itself.
Mathjax reminds me of the AJAX hype. What happened to it? These days no one talks about AJAX. There was material design a few years later but that was just the looks.
Is AJAX now replaced with React.js? or a combination of other stuff (like HTML5 and modern-JS and React.js and stuff)?
edit: I just looked up Angular and apparently it was rewritten in Typescript, a strict superset of JS. This doesn't make sense. JS is known for massive amounts of cruft. An improvement would've been a scripting language that compiles to "JS: the good parts", i.e., a subset of JS. But now we should have "Typescript: the good parts" because TS inherited all the bad parts of JS?
edit 2: It turns out, there is valid JS that is invalid TS [0]. And yet, TS is described on wikipedia as "a strict superset of JS" [1]. (invalid TS == non-error-free TS).
edit 3: Further confirmation about error-free TS not being a strict superset of JS [2]. Such a lie can only be expected from a company like micro$hit.
edit 5: even with-error TS is not a superset of JS (the behavior is different) [3].
edit 6: Typescript is an opinionated-yet-spineless Javascript!
FWIW, Mathjax doesn't have much to do with AJAX calls.
AJAX is just ubiquitous and it's easier to use without frameworks nowadays. React is a library that solves different problems from the frameworks that made AJAX easier like Prototype and jQuery.
React helps folk build UIs through interesting data-models and the ShadowDOM. AJAX is required by anything but the most trivial React projects to make server-side requests.
AJAX is just a set of principles to make client side web applications more dynamic by getting all the data async and updating the DOM. AJAX is very much alive in modern client side js frameworks like Angular, react etc... It is just abstracted away a little (or a lot).
AJAX hype is like indoor plumbing hype. Everyone realized it was good, and now it's everywhere all the time, although only plumbers talk about it.
I think your footnote [3] is a reference to an HN comment of mine. I think you should know I actually like typescript even though the "superset of JS" thing is a bit oversold.
For context, as somewhat of an outsider, I knew about Crockford 'JS: The Good Parts' and knew the community cared about working within the limits of a sane "subset" of JS.
A few years later, I hear Typescript is everywhere and JS folks love it. I didn't pay attention to what it really claims to be, but made a connection with the Crockford book, and started mentioning in discussion with acquaintances that it's a subset of JS (it must be because that's what the community wanted).
Lo and behold, one of them heard TS is a "superset", not a subset, and dissed me as a knowledgeable tech person, despite himself knowing so little that barely weeks ago he didn't know the difference between Java and Javascript.
You can scroll through https://ultimateelectronicsbook.com/systems-of-equations/ for a particularly formatting-heavy example with lots of matrix equations and augmented matrices, working through Gaussian decomposition and LU factorization examples.
Instead, for performance, I wrote a small Ruby / Jekyll plugin to do MathJax server-side rendering. It calls the mathjax-node npm package, with some caching on top because it's so slow. This outputs static HTML and CSS with a few math fonts.
The mathjax-node-sre npm package even populates aria-label fields for each equation:
If you have the option to consider server-side equation rendering, your users may thank you.