33 ms·

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 serv

by osrec 4y 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.

Gelitio 4y 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.
civilized 4y 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.
- selestify 4y ago
  As someone with no experience in the area, what have been the problems of the past decade?
  - civilized 4y ago
    I don't know why, but the rendering just wasn't that reliable. Equations failed to render too frequently.
lelandfe 4y ago
The tradeoff is exactly noticeable slowdown: https://imgur.com/a/y47haf9 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.
- diegof79 4y ago
  > 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.
  - lelandfe 4y ago
    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 4 times.)
    - osrec 4y ago
      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.
      - lelandfe 4y ago
        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.
delta_p_delta_x 4y 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-basic-tutorial-and-quick-reference https://math.meta.stackexchange.com/questions/5020/mathjax-b... [1]: https://www.intmath.com/cg5/katex-mathjax-comparison.php https://www.intmath.com/cg5/katex-mathjax-comparison.php [2]: https://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.html https://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.h...
- osrec 4y ago
  On my machine the first link loaded in under a second. On my mobile it was about 3 seconds, but it didn't feel especially sluggish. Even then, I'd say stackexchange has a somewhat inefficient implementation, in that they're trying to render everything in one shot. For example, I see no reason why they wouldn't just render the stuff that's in view first, and the rest is rendered incrementally as the user scrolls, or a few seconds after the initial paint. I take your point that KaTeX is faster in absolute terms, but from a usability point of view, the benefits do not outweigh the costs in my opinion.
  - delta_p_delta_x 4y ago
    > the first link loaded in under a second. On my mobile it was about 3 seconds Did you wait for the typefaces to change to Computer Modern? On my smartphone, this took ages, and that is what I implied by 'fully loaded'; more complex maths is unreadable on some devices with only the native typefaces. Even a (relatively straightforward) cube root doesn't look clean[0]. MathJax has (from my observation) two 'levels' of rendering, where it uses the OS native typeface for a first pass, and then renders everything in Computer Modern for a uniform look (except on Apple devices, which somehow override this with STIX fonts). Needless to say, the typeface change means that the dimensions of the maths content change, causing the rest of the website to reflow a second time. This second render takes the bulk of the time, and having a website's content unexpectedly jump around a long while after it has (apparently) loaded is not exactly user-friendly. [0]: https://imgur.com/a/CrKqeI5 https://imgur.com/a/CrKqeI5
muhehe 4y 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.
- osrec 4y ago
  Interesting point of view, but I feel you're missing the point. Do you find all native applications rude to customers?
  - muhehe 4y ago
    No. I'm absolutely expecting local native app to do all the work, it makes sense. With SAAS running in the browser I expect all the heavy lifting is done somewhere else...you know, as a service.
xigoi 4y ago
So use KaTeX on the client side. It's still much faster than MathJax.
- osrec 4y ago
  Yes, agreed. I was just saying that client side rendering makes more sense; which library you choose is up to you.

by osrec 4y ago

Gelitio 4y 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.

civilized 4y 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.

selestify 4y ago
As someone with no experience in the area, what have been the problems of the past decade?
- civilized 4y ago
  I don't know why, but the rendering just wasn't that reliable. Equations failed to render too frequently.

lelandfe 4y ago

The tradeoff is exactly noticeable slowdown: https://imgur.com/a/y47haf9 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.

diegof79 4y ago
> 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.
- lelandfe 4y ago
  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 4 times.)
  - osrec 4y ago
    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.
    - lelandfe 4y ago
      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.

delta_p_delta_x 4y 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-basic-tutorial-and-quick-reference https://math.meta.stackexchange.com/questions/5020/mathjax-b... [1]: https://www.intmath.com/cg5/katex-mathjax-comparison.php https://www.intmath.com/cg5/katex-mathjax-comparison.php [2]: https://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.html https://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.h...

osrec 4y ago
On my machine the first link loaded in under a second. On my mobile it was about 3 seconds, but it didn't feel especially sluggish. Even then, I'd say stackexchange has a somewhat inefficient implementation, in that they're trying to render everything in one shot. For example, I see no reason why they wouldn't just render the stuff that's in view first, and the rest is rendered incrementally as the user scrolls, or a few seconds after the initial paint. I take your point that KaTeX is faster in absolute terms, but from a usability point of view, the benefits do not outweigh the costs in my opinion.
- delta_p_delta_x 4y ago
  > the first link loaded in under a second. On my mobile it was about 3 seconds Did you wait for the typefaces to change to Computer Modern? On my smartphone, this took ages, and that is what I implied by 'fully loaded'; more complex maths is unreadable on some devices with only the native typefaces. Even a (relatively straightforward) cube root doesn't look clean[0]. MathJax has (from my observation) two 'levels' of rendering, where it uses the OS native typeface for a first pass, and then renders everything in Computer Modern for a uniform look (except on Apple devices, which somehow override this with STIX fonts). Needless to say, the typeface change means that the dimensions of the maths content change, causing the rest of the website to reflow a second time. This second render takes the bulk of the time, and having a website's content unexpectedly jump around a long while after it has (apparently) loaded is not exactly user-friendly. [0]: https://imgur.com/a/CrKqeI5 https://imgur.com/a/CrKqeI5

muhehe 4y 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.

osrec 4y ago
Interesting point of view, but I feel you're missing the point. Do you find all native applications rude to customers?
- muhehe 4y ago
  No. I'm absolutely expecting local native app to do all the work, it makes sense. With SAAS running in the browser I expect all the heavy lifting is done somewhere else...you know, as a service.

xigoi 4y ago

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

osrec 4y ago
Yes, agreed. I was just saying that client side rendering makes more sense; which library you choose is up to you.