Live data from Hacker News

Render mathematical expressions in Markdown On GitHub

github.blog

91–100 of 114 posts

Re: Render mathematical expressions in Markdown On GitHub

#91
post #56

Earlier quoted context omitted.

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" fa…

> 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 thir…

On my iPad Pro (2018), the first page rendered fully within seconds. I’d never visited the page before. I scrolled down and up the entire page to check.

Re: Render mathematical expressions in Markdown On GitHub

#92
post #8

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…

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

Re: Render mathematical expressions in Markdown On GitHub

#93

Earlier quoted context omitted.

> Browser JS engines are single threaded The JS interpreter is single threaded. But, you can offload the work to a web worker, that runs another instance of the interpreter in a separate thread. Also for rendering LaTex it’s possible to optimize the rendering algorithm using WASM. I’m not saying that MathJax does that, or it has good performance. But, there are options to optimize the client side rendering.

Workers lack document access and have to schedule updates with the main thread. That puts us back where we started (plus the overhead of starting the web worker). I don't know enough about the state of WASM today to say the same. Circa 2018 I know that it lacked DOM manipulation. (In some distant year I will figure out the incantation to avoid getting sniped when talking about this stuff. I think I rewrote that line…

It doesn't put you back where you started at all. One thread aggregating the results from other workers and applying them to the DOM is not at all the same as a single thread doing all that work on its own.

Re: Render mathematical expressions in Markdown On GitHub

#94
post #93

Earlier quoted context omitted.

Workers lack document access and have to schedule updates with the main thread. That puts us back where we started (plus the overhead of starting the web worker). I don't know enough about the state of WASM today to say the same. Circa 2018 I know that it lacked DOM manipulation. (In some distant year I will figure out the incantation to avoid getting sniped when talking about this stuff. I think I rewrote that line…

It doesn't put you back where you started at all. One thread aggregating the results from other workers and applying them to the DOM is not at all the same as a single thread doing all that work on its own.

Let me rephrase: distributing work to web workers won’t be faster in first page load than images in this conversation.

Because we have to participate in the main thread either way, prerendered images will always paint faster. There is simply too much action in the thread during the initial GitHub page lifecycle. The 40-50ms (~one long task) cost of spinning up a new web worker just solidifies that.

Re: Render mathematical expressions in Markdown On GitHub

#95
post #56

Earlier quoted context omitted.

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" fa…

> 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 thir…

On my mobile, for [1] KaTex loads in 900ms, MathJax in 1200-1600ms. Good enough for client side usage.

Re: Render mathematical expressions in Markdown On GitHub

#96

Why don’t web browsers just add a tag for mathematical expressions ?

Of course there it is [1], but Chrome doesn't support it and is essentially blocking its adoption. And it is not like MathML is too taxing to browsers; Firefox and Safari had a support for a long time and actually Chrome also once had a support before being dropped due to the instability! [2] The implementation is still underway but is not prioritized enough by Chrome developers.

[1] https://www.w3.org/TR/MathML/

[2] https://caniuse.com/mathml

Re: Render mathematical expressions in Markdown On GitHub

#99
post #56
post #8

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…

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" fa…

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

Re: Render mathematical expressions in Markdown On GitHub

#100
post #8

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…

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

Rendering HTML doesn't require a huge JS library.
Post reply on HN