top | item 31440148

(no title)

romeovs | 3 years ago

Nice! A welcome addition!

Too bad they're not using KaTeX [0] instead.

It renders the maths server-side, so there's no runtime needed.

An additional bonus is that the resulting math is copy-pasteable, which in the case of disply math might not be that useful (since most equations are to complex to be meaningfully copy-pasted with unicode), but it helps from inline math dissappearing when copy pasting texts.

But, that being said, I'm sure they had their reasons to do so. For one, MathJax seems more well-known by quite a bit so maybe it's the safer option.

1: https://katex.org/

discuss

order

osrec|3 years ago

If I was building this feature, I'd also pick client side rendering, simply because at GitHub's scale, rendering on the server side will require a bunch of servers, which will need to be managed and looked after.

By offloading the rendering to the client, you make use of the spare capacity that exists on most client machines today, with no noticable slowdown for the user (it may even end up doing the "first paint" faster in the browser if GitHub are careful about their implementation).

Even with my SaaS product, we try and do as much work on the client as possible to reduce our server requirements. If you're sensible about it, users don't even notice.

delta_p_delta_x|3 years ago

> while no noticable slowdown for the user (it may even end up doing the "first paint" faster in the browser if GitHub are careful about their implementation).

Have you visited math.stackexchange? Pop by their MathJax reference page[0], and observe how long all the mathematical notation takes to render fully—it takes at least six seconds on my recent notebook, plugged in. On my 2018 iPad Pro, it takes well over thirty seconds on the first page load (drops to ~5 s on subsequent visits: there's probably some caching going on).

Here's[1] a benchmark comparing KaTeX (server-side), MathJax 2.7, and MathJax 3.0 (apparently a complete rewrite supporting server-side rendering[2], but it's still noticeably slower than KaTeX).

MathJax is really slow (slower still than LaTeX itself, and that's saying something).

[0]: https://math.meta.stackexchange.com/questions/5020/mathjax-b...

[1]: https://www.intmath.com/cg5/katex-mathjax-comparison.php

[2]: https://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.h...

lelandfe|3 years ago

The tradeoff is exactly noticeable slowdown: https://imgur.com/a/y47haf9. Browser JS engines are single threaded, so MathJax has to wait its turn behind more important scripts, and it gets worse with slower devices and networks. It's a contest of download vs execution time, which a 2KB pre-rendered image will always win.

You're right on the money with the server costs though.

muhehe|3 years ago

Sorry, but I find this approach very rude to your customers. It's kinda your job to make it work on your side and don't transfer the burdens to clients.

I don't know what your SAAS does (maybe it's not really applicable here), but in the case of github, it's very wastefull. Yes, it would take some work, some servers, etc but they have the skill, the money and everything they need to do it. They could do it once (well, with every change, but it's not very often) on their side instead every client on every pageview will have to do the same work again and again, wasting time and energy.

civilized|3 years ago

Historically client-side rendering has been a big headache. Not sure if it's improved recently, but avid math bloggers and blog readers will remember the problems of the past decade.

Gelitio|3 years ago

I would probably pretender it.

Why?

Because markdown files seldom change and probably read much more often.

Anyway I would not agree that it is a good idea to move everything to client just because you can. There are always up and downsides.

I think your comment is too generic.

xigoi|3 years ago

So use KaTeX on the client side. It's still much faster than MathJax.

joppy|3 years ago

For pages with lots of mathematics markup, it is far better (in terms of download size) to send the latex markup and the katex library to the browser, and render it there. I tried rendering the mathematics server-side using katex on my own website a while ago, and the div soup generated by katex takes up loads of space.

Original page (compressed): 10 kB

Page with server-rendered Katex (compressed): 50 kB

Katex.js (compressed): 80 kB

So after two pages it’s a net win to not render the mathematics server-side.

dllu|3 years ago

For my blog (e.g. https://daniel.lawrence.lu/blog/y2021m09d08/ with tons of math), I render the math serverside using MathJax and serve them as SVG images (with alt text for the visually impaired). They get cached too which is nice especially since many symbols are duplicated. Seems fast enough for me.

mk12|3 years ago

I used to think KaTeX was far superior to MathJax but now I'm not so sure. I made https://mk12.github.io/web-math-demo/ to compare them and other things. They're definitely superior to browser MathML rendering today, which is nonexistent in Chrome (though see https://mathml.igalia.com/), quite bad in Safari, and OK in Firefox. It's true pre-rendering KaTeX produces a lot of markup, but it compresses very well so I don't think it's a big deal. They both have MathML for accessibility, but MathJax is more flexible in letting the user right-click and change the rendering engine, view raw TeX, etc. Rendering KaTeX on the client side is faster than MathJax, but in my experience KaTeX is slightly worse quality, e.g. https://github.com/KaTeX/KaTeX/issues/3400 has gone unfixed for a long time.

williamstein|3 years ago

There's currently around 100 LaTeX functions listed as "Not supported" in the Katex docs at https://katex.org/docs/support_table.html I've been trying hard for a while with my site (https://cocalc.com) to use only katex, but that's definitely never going to happen. Users frequently hit missing functionality, e.g., they have lots of notebooks that use "\mbox", so it's critical to support full mathjax. I currently do this by attempting to use katex, then falling back to mathjax if it fails. That said, as you point out, mathjax has massively improved over the last few years with mathjax3! Thanks for pointing out the quality issues, which I hadn't thought about.

runarberg|3 years ago

The last I knew, KaTeX had issues with accessibility. But honestly it is probably just best to ship raw MathML, translated from LaTeX on the server, and use MathJax as a polyfill for Chrome and Edge users. That way you get extremely fast rendering in Safari and Firefox without any extra javascript, and eventually Chrome will catch up.

mk12|3 years ago

I wouldn’t recommend relying on Safari MathML rendering today for anything but very basic equations. Firefox is a lot better, but still not quite at MathJax quality. I made a demo here https://mk12.github.io/web-math-demo/ that lets you compare them. Also if you edit the MathML markup box, it will render directly from that, just like the poly fill (sometimes the layout shifts slightly when switching from TeX -> MathJax HTML+CSS to TeX -> MathML -> MathJax HTML+CSS).

jscholes|3 years ago

> I'm sure they had their reasons

They do, accessibility being one of them. Rendering math in the way you describe makes it difficult, or impossible, to understand for all sorts of audiences, including those relying on screen reading software.

powersnail|3 years ago

MathJax can do server side rendering too now!

ThinBold|3 years ago

Maths don't scale up. Moore's Law will catch up and eventually rendering math will be like rendering jpg. For now the priority is to get things to work so we don't waste extra time determining if we just avoid math or we use stupid PNG.

qumpis|3 years ago

I'm so happy that I can just paste my definitions from latex preamble into a paragraph to include all the calitographic symbols and other conveniences with Mathjax. As far as I know, I can't easily do it without adapting to Katex-specific syntax.

barnabee|3 years ago

Everything else on a web page is rendered client side (HTML is just text…) so client side rendering makes sense to me here too.

xigoi|3 years ago

Rendering HTML doesn't require a huge JS library.