Introducing Tesserax

A pure Python, developer-friendly library for academic drawing.

Photo by KOBU Agency on Unsplash

It is 2026. We are still treating scientific diagrams like cave paintings.

I have a PhD in Machine Learning. I can explain the mathematics of high-dimensional manifold optimization. Yet, until recently, if I wanted to draw two boxes connected by an arrow, I had to Google the syntax.

My diagrams were dead artifacts. While my code was version-controlled and modular, my figures were fragile binary blobs or brittle LaTeX macros. I needed my drawings to behave like the rest of my research.

Instead, I found myself trapped between two equally bad options.

I have spent weekends fighting Mermaid and Graphviz. They are fine for a quick flowchart. But try asking them for a publication-quality Turing machine. Try asking for a precise computer architecture diagram. You hit a wall.

Using these black-box layout engines is like trying to parallel park a bus while shouting instructions from the sidewalk. You can nudge the parameters, but you never quite end up where you want to be.

The real sin of these tools is their refusal to encapsulate. As developers, we take parameterization for granted. We define logic once and instantiate it a thousand times. But you cannot take a Mermaid diagram, wrap it in a function, and ask it to render a version with “n” nodes. Our drawing tools should respect the engineering principles we teach.

Then there is TikZ.

TikZ is the undisputed masterpiece of academic drawing. It offers total control. It is also fundamentally broken for the web.

TikZ is a “print-first” citizen. If you convert it to SVG for a blog post, you don’t get a clean vector drawing. You get a crime scene. Inspect the element, and you will see a soup of unreadable paths that no CSS can touch.

And then, there is the “Reviewer #2” problem. (Damn Reviewer #2, why is it always you?!) You spend three hours perfecting a TikZ architecture diagram. You submit the paper. The review comes back: “Please swap layer 3 and layer 4.” In a drag-and-drop tool, this is annoying. In TikZ, it is a reconstruction project involving fifty lines of coordinate hard-coding. It isn’t just tedious; it’s fragile.

To render my documentation in a CI/CD pipeline, I shouldn’t have to install four gigabytes of TeX Live just to draw a few circles. And there is the friction of the language itself. Writing geometry macros in a specialized DSL is a jarring context switch. It forces you to leave the logic of your Python research and enter a world of backslashes and curly braces just to visualize a result.

Meet Tesserax

The shift happened when I moved my academic publishing to Quarto.

Quarto is essentially Jupyter on steroids. Since Jupyter is the standard for scientific computing, the solution was obvious. We didn’t need another GUI. We didn’t need a new domain-specific language. We needed a Python library that could live inside the notebook and speak fluent SVG.

I built Tesserax to close the gap. I started with the atoms, like Rects, Circles, and Paths. But the breakthrough was the Anchor System. I wanted a “nervous system” for diagrams, where objects know where they are relative to one another. No manual coordinates. No magic numbers.

Tesserax is what happens when you treat a drawing as a function of state.

In Tesserax, you don’t place a node at (100, 200). You define a Layout. You say, “I want a column of nodes, and for every node, I want an arrow pointing to the next one.”

# This isn't just a drawing. It's logic.
with Canvas() as c:
    nodes = [Circle(10) for _ in range(5)]
    layout = Column(nodes, gap=20)

    # If I add a node to the list above, the arrows update automatically.
    for n1, n2 in pairwise(nodes):
        Arrow(n1.anchor("bottom"), n2.anchor("top"))

This snippet doesn’t just render a figure. It renders any version of that figure. It captures the abstraction, not just the pixels.

The Rationale Behind Tesserax

But why, Alex, why building something like this? Don’t you have enough in your plate now?

Well, first, who are you and why do you know me so well? Second, it’s fun! But if that isn’t enough by itself, let’s analyze the landscape of modern academic drawing.

First, there is Matplotlib.

It is the industry standard for a reason. If I have a CSV of training data, Matplotlib is my first call. But have you ever tried to draw a linked list in it? You end up fighting the axes. You spend a dozen lines of code just hiding the ticks and borders to get a blank canvas.

Matplotlib is a library built for statistics that is occasionally forced to perform geometry. It feels like doing calligraphy with a highlighter. Tesserax respects the division of labor: use Altair or Matplotlib for your data, and use Tesserax for your concepts.

Then, there is Tikz. (Again!) We already discussed it, but there is more.

On one hand, there is a strange Stockholm Syndrome in academia. We accept that drawing a simple three-state automata requires learning a bizarre macro language on top of another macro language (yeah, I’m looking at you, LaTeX!). We treat TikZ’s loop syntax like a revelation, ignoring that any programming language is actually better at this, but I can also have, I don’t know, variables! And also, who the hell knows how to write Tikz!? (I know some of you nerds do, don’t give me that look. Shame on you.)

Tesserax bets that you don’t need a Domain Specific Language (DSL). You need objects. You need classes. You need type hints. If you want a grid of shapes? That is a nested list comprehension. If you want a recursive tree? That is a recursive function. You don’t need to “learn Tesserax.” You just need to know Python. By piggybacking on Python’s syntax, we get free IDE support, linting, and the ability to debug our drawings with the same tools we use to debug our kernels.

But also, even more important, the browser is the new print driver. TikZ was built for a world where the final output was a piece of paper. Tesserax is built for a world where the output is a responsive HTML page that can be printed.

By targeting SVG natively, we bypass the fragile conversion layers. We get semantic scaling. We get CSS styling. We stop fighting the renderer and start using the most optimized vector graphics engine in history: the modern web browser. And you can render SVG to PDF anytime. Going back, though, means you lose the semantics of what your drawing means.

And last but not least, Tesserax is lean. Like, zero dependencies. A couple hundred of pure, fully-typed, Python 3.12. Nothing more, nothing less.

I rest my case.

What’s Next

So Tesserax is my attempt to bring software engineering to scientific illustration. I’m releasing it today in a very crude, 0.2 something version, as I always do, to gather as much feedback as possible as soon as possible. From now on, all the diagrams in my papers, blog posts, and books will be built with this.

So, next step, I’m moving past the primitives phase now and into building high-level scientific abstractions. I want to generate automata that look like they were pulled from a classic textbook and data structures that reflect actual memory layouts. That’s what comes in the next few iterations. Moving from a world where we draw lines to a world where we code diagrams.

I’d love it if you’d give Tesserax a try. The documentation is still pretty thin but feel free to drop me a comment with any questions or suggestions.