Should we have MathJax in MVP?

One thing we eventually want to have is MathJax (or equivalent) support. But the question is, should we already have it in MVP?


A minimum viable product has just enough core features to effectively deploy the product, and no more. - Wikipedia

That would be my answer, but I don’t want to come off as snappy, so I’m adding more text here. I know that our current description of our MVP does not really follow this description 100%, and you could argue that there is some leeway in interpretation for some things.

However, from my perspective the answer to this one seems clear; I’ve been a moderately avid SE user for a couple years now and I have never used it (actually had to look it up to be 100% sure what it is).

We should get that in before we start a math community, but we’ll probably start off with a meta and then something about programming (just my guess, I have not heard anything about actual plans).


It sounds similar to the question of Hebrew keyboard for Mi Yodeya. A nice to have item, vital for one community but not MVP to go live for most communities.


I don’t know what your definition of one is, but I count at least five: math, physics, computer science, worldbuilding, Mathematica. Or six, if you count Mathematics.SE and MathOverflow separately.

And that are only those I know of.


MathJax is important for certain types of sites and essential for some, but that doesn’t mean it’s MVP for Codidact. Question: how hard is it? Is it “just” a matter of adding a library to whatever does CommonMark, or does it require us to do extensive work, or something in between? (I’m wondering if we should have the idea of “not MVP but low-hanging fruit; do if it makes sense”, and if so if this is in that category.)


I’d say it depends on the level of integration you aim for.

If you just enable it for the finished posts, the main work would be making sure that the MarkDown engine doesn’t try to interpret the MathJax code. Other than that, I think it should be just adding the JS library and inserting a few JavaScript commands into the page (at least that’s what it looks like to me from the MathJax page; I don’t have any experience on this). The disadvantage for the user would be that you don’t see your math errors until you posted.

Note that MathJax acts in the browser; no actual math rendering is done on the server. All the server has to ensure is that the math code gets included in the output page unmodified (except for HTML entity encoding).

If MathJax is included in MVP, it might be at this level.

One also might add a “preview math” button to MathJax enabled sites, which would then trigger a preview math rendering. I have no idea how easy/complicated that would be. Certainly would only be in MVP if easy to do.

I believe a live preview during typing (as in StackExchange) would be more work. Probably not MVP.

And a really good integration (beyond what SE does) would be quite a bit of work. Definitely not MVP.


On one hand, adding MathJax is relatively easy, as it is essentially just a front-end library, on the other hand it’s simply not universal enough, in my opinion. If MathJax included more of the TikZ capabilities, for drawing graphs, diagrams, etc. I’d say yes. However, this is not the case, in which case I can’t say I’m in support for this, as it has henceforth limited use for things not relating to math.

Creeping featurism is a thing, removing a dependency is almost always beneficial to a more lighter product. If there is a LaTeX-related library in existence adding more typesetting capabilities that are more universal to textual or more general diagram rendering, I’d say yes, however I’m not aware of such (JS) library. A good example is CircuiTikZ. It’s not available with MathJax or similar libraries, but it would be very much handy for an electronics based website. If such a library was able to render the tikzpicture environment, my stance would be in favor of that. Just the math environment with MathJax, is not enough for MVP in my opinion.

So just to clarify, @polemon, you’d rather we didn’t include any sort of math rendering in MVP unless it includes graphing capabilities?

Bear in mind that this is MVP - i.e. minimum viable product - not “all the features we want in a ‘finished’ version”.

I don’t think so. Eventually it should be available however.

<embarrassing confession>
I wrote over 6500 answers on Electrical Engineering SE, and never used MathJax even though many posts contained equations. I did make heavy use of HTML tags like <sup>, <sub>, and the &xxx; syntax for special characters like Π, ω, θ, and the like. You can get a lot done with those. Make sure those HTML elements are supported in MVP.

I agree that MathJax can make better equations than HTML, and that eventually you need it for technical sites. Perhaps for sites like Physics it is mandatory, since equations tend to be more complicated than those for EE.

The reason I never used MathJax is that it was always one more thing to look up and learn, and I just never got around to it, and never ended up with enough of a need to force me to learn it.
</embarrassing confession>


I never once used the built-in schematic editor on the SE EE site, and I posted a lot of schematics. Anyone that can spell EE already has some package they use for schematic capture. These packages all have their idiosyncrasies, so learning and getting comfortable with a new one is a significant investment. I used Eagle (free version is available that is plenty good enough for just drawing schematics), and exported the result to an image file.

Of course, you absolutely must have image file insertion for MVP, at least for questions and answers.


Yep, pretty much. MathJax and it’s math rendering - while wonderful, just doesn’t make sense if used for something geared towards discussing Japanese literature and language, for instance. If it was a more universal tool, sure, there’s an argument for including it in the baseline system. I hope that makes more sense? I mean tbh. I’m torn on this myself, too. Adding mathjax.js is comparatively not a big deal, but it’s just not a universal-enough tool to be included in MVP.

If there was a JS library, that provided tikzpicture but not LaTeX math mode, I’d say, sure, go right ahead, you can use diagrams and grid based line rendering in almost any science and any topic. Ranging from literature and creative writing, to theoretical physics.

So i’m arguing purely based on the universality of it. Markdown is superbly universal, no matter the subject, it makes sense to use it to compose any sort of questions and answers. Using diagrams makes sense in nearly all subjects, too. But math rendering? Not so much, I’m afraid.

I’m not saying I’d want MathJax to render tikzpicture code. I’m saying that if there was a library that did that, I’d argue to include that one in MVP over MathJax. However, if MathJax did render tikzpicture code, the argument to use MathJax in MVP would be much stronger. However, as it is right now, I’d say don’t include MathJax in MVP. It’s just not universal enough, so you might relegate it to individual instances.


Whether MathJax or some other LaTeX rendering is MVP depends entirely on who is gonna use it.

On stats.SE the use of equations in answers is roughly half the time.


In an abusive display of RFC 2119 terminology, I’d say we MAY have MathJax for MVP, but not SHOULD, and definitely not MUST.

Not hard. More or less the same work as implementing the markdown engine. Possibly even less work!

p.s. Hope we don’t have to support <embarrassing confession> blocks :sweat_smile:


It’s relatively easy to slap it on, and it kinda just works. However on a slightly broader scale, it kinda depends on the implementation variant. MathJax is kindof the full-featured math rendering library, slow but lots of bells and whistles, while katex.js is a much more lighter variant (also quite easy to add to anything), but has fewer features. It cuts down time when opening the website, etc. as it’s rendering engine is much faster.
Having used both, as in adding them to websites, I can say both are easy to add to an existing website; but it still adds an additional dependency, and complexity (however little).


Due to the fact that the integration of MathJax is relatively easy and it is a basic need for many potential communities, I am tempted to say that it should be in the MVP.

I am certainly biased; however, I would limit it to basic MathJax without any additional packages (for example, Chemistry SE now uses MathJax-mhchem to render the formulas).


This. If I thought there was a possibility of a viable physics community any time soon I would push hard for MathJax.

But the users of physics.stackexchange are by and large a pretty insular bunch as far as network politics go. And the other sites I used to use that make heavy use of MathJax are mostly pretty small in the first place.

Worldbuilding uses Mathjax and I suspect (haven’t asked them) might join. But that doesn’t mean MVP; it just means “keep the idea in play”.

If according to everyone, MathJax is easy to integrate then I propose that we integrate it (involve in MVP).
Case study involves numerous requests on meta SO for enabling mathjax.

1 Like

There are other sites that have it too, although not every site uses the same syntax oddly enough. Code Review has some version of it too, used like this: \$123\$ is \$321\$

Often enough (but far from consistently) used when quoting parts of programming-challenges that are already written like that (like Hackerrank).

We just implemented MathJax on TopAnswers and found it a pain in the neck — not to get it working, but to configure and to understand all the security implications etc. It’s a very heavyweight library.

Fortunately Code Golf don’t really need it because when I asked they said KaTeX “is plenty powerful for our needs”. It’s much simpler for us to implement securely, and it’s faster too.

Whether there are any communities that absolutely require MathJax over KaTeX is a hurdle I’m glad to be able to put off until we are further down the road! Incidentally MathJax 3.0 looks like it will make a lot of things easier, but it isn’t an option for us (yet) because:

The Safe extension has not yet been ported to version 3, but should be for a future release