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…
Render mathematical expressions in Markdown On GitHub
91–100 of 114 posts
Re: Render mathematical expressions in Markdown On GitHub
#92Nice! 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…
Re: Render mathematical expressions in Markdown On GitHub
#93Earlier 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…
Re: Render mathematical expressions in Markdown On GitHub
#94Earlier 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.
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
#95Earlier 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…
Re: Render mathematical expressions in Markdown On GitHub
#96Why don’t web browsers just add a tag for mathematical expressions ?
Re: Render mathematical expressions in Markdown On GitHub
#97Complex equations is still broken. Too sad. e.g., https://github.com/chazeon/notes/blob/master/docs/notes/ml-p...
Re: Render mathematical expressions in Markdown On GitHub
#98Re: Render mathematical expressions in Markdown On GitHub
#99Nice! 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…
Re: Render mathematical expressions in Markdown On GitHub
#100Nice! 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.