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

# Should we have MathJax 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 *

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.

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