[chrismorgan]

You’re misunderstanding what “client-side rendering” means. It’s not about rendering to images, it’s about rendering to HTML/CSS/SVG/whatever.

“Client-side rendering” means that what is served contains something not in the eventual form you desire to present it, and that it depends on some client-side scripting to convert it into the desired form. When the page loads, it will first show perhaps nothing or perhaps something like $e^{-\frac{x}{2}}$, and then the scripting will kick in and replace that with the proper HTML/CSS/SVG/whatever markup for the equation that the browser knows how to display.

“Server-side rendering” means that you do this translation from $e^{-\frac{x}{2}}$ to the desired HTML/CSS/SVG/whatever that the browser knows how to display, on the server, so that the browser can immediately display what it receives. Ideally this translation is also only done once, rather than on every request.

[crazygringo]

I know it's rendering to HTML/SVG whatever, but I still think that belongs client-side.

It's better to do it on the client because it's generally better to send less information over the wire, as well as send information in its most unprocessed form.

This applies, for example, to charts as well -- far better to send the raw data series values to the client and render it on the client-side with a charting library.

Both of these cases have the huge advantage that if you want to use the equation or data yourself, you can just "view source" or "inspect" and grab the equation or data directly to copy.

I don't think we need to be too concerned about the fact there's a slight delay in rendering equations. People are pretty used to browsers loading everything gradually, whether waiting for images to be the last thing to appear, or even lazy loading of images. There's nothing wrong with that.

[int_19h]

But does this actually work well for layout? i.e. if you generate HTML/CSS output from math formulas server-side, will it correctly (from the math typography perspective) reflow if the viewport is resized etc?

[chrismorgan]

I don’t know whether MathJax/KaTeX do anything special about wrapping. They could hard-code the lot, they could use markup and styles that will leave the browser to handle wrapping, or they could do active reflow where they adjust the DOM depending on the available space. But server-side rendering is still feasible and desirable even in that last case: you render to some baseline markup that will work in all cases but perhaps not have ideal layout, and then add a bit of optional JavaScript to reflow and optimise the layout. Ideally you separate the mathematical markup rendering from the reflow completely, so that you can ship much less JavaScript (more targeted and faster JavaScript, at that).