Marimo export could be so much better for websites !

[rambip]

Not long after discovering Marimo, I decided I wanted my website to be generated by Marimo, with a pure Python pipeline.
Currently, it looks like this: https://rambip.github.io/

It's very hacky, and I was always frustrated that exporting to a website did not have first-class support in Marimo.

The release of Marimo Anywhere was the occasion to express my problem in a more precise way.
There are 3 kinds of things that I don't like with the current export strategy/philosophy, and here they are:

1. t's based on islands, but islands are opaque, not hackable, no way to disable the "run all" behaviour, slightly bloated so page loads are a bit long. I don't want to pay for all the Marimo JS components all the time; I would like a more fine-grained export logic that would detect what components are needed. Also, I would like to change the style of a lot of components for my website; often I can't do it via CSS only, and sometimes I would like to change the JS logic too.
2. The phase where the assets are built is not the one you expect. Basically, I would like Marimo export to generate all the assets, a bit like the Marimo export session works. But I would like the assets to be stored in a directory. Instead, marimo-anywhere exports the Python file as markdown with code, and the generation happens again at a later phase. Why is that the case? I don't see why it's built this way.
3. I really value (like many other users I think) a 100% Python pipeline. I saw a lot of people complaining about how Quarto behaves with Marimo, for dependencies, for example. For other React-based website generators, it's the same. People on discord keep explaning that they want a pure python solution. I would love an API that would enable me to generate my HTML pages directly from the Marimo notebooks, but in a way that is easy to configure.

Now, let me answer some questions:

We are trying to find the right balance between providing a great user experience while not reinventing any static site generator framework. Quarto, Jupyter Book and MDX-based site generators like Next.js, Nuxt.js, Astro, pure React + Vite, etc. all provide solutions for common needs like navigation, site search and best practices around deployment. What configurations would you like to adjust in such a fully Python pipeline? Also, would you expect this pipeline to be optimised for publishing a single notebook or a collection of notebooks?

The basic idea of exporting to a mdx component is fine, as long as it's a small, interactive, independent, compute-friendly element. But often, elements are not like this.
The only think I want is a good API to work with it. The marimo team already did a great API design job for marimo-pair, and I think it should be the same for exporting. Your LLM should be able to do from marimo import export, and from there, it should be able to do things like:

• running the entire notebook (with different options ?), get the cells results and collect assets (both image produced by the kernel, mo.image elements, mo.audio elements, but also generated files. Maybe, the hard part would be to not duplicate outputs (like if someone does create_image("./foo.png"); mo.image("./foo.png") ? IDK)
• get the list of links the marimo elements are exported from, being able to overwrite some elements (ideally we would like to make all the marimo Elements importable individually from js, so that the user can hack on them)
• generate a page from a jinja template, with islands enabled or disabled
• having a function that does exactly the same as the current export feature, but with a few options (title, url, meta, favicon ...)
• being able to generate it from the json session file instead, when the notebook is heavy
• maybe having a way to include a "open in molab" button, but you would configure it with molab server or wasm depending on how heavy the notebook is ? Also, it could be interesting to have a hybrid mode, like a "hydration" button that would turn the static notebook into a dynamic one.

One things that could be hard to get right here is caching, I don't know. That's very valuable to re-run only the notebook that changed when you're creating a website-generator-script. But caching is hard.

Here are some issues that this work could solve:

• Export notebook as markdown with output #3692
• New export format: Typst #8903

A different one but that I would love to see fixed too: #9890

Feel free to ask as many questions as you want to clarify the need. I hope this discussion will be fruitful

[peter-gy]

Continuation of this Discord thread

Hey @rambip, thank you for the feedback!

But I would like the assets to be stored in a directory. Instead, marimo-anywhere exports the Python file as markdown with code, and the generation happens again at a later phase. Why is that the case? I don't see why it's built this way.

With mdx-marimo, jupyter-book-marimo and quarto-marimo, the first step is conversion of your notebook Python file into the specific format mdx, jupyter-book or quarto expects. It is purely a code-conversion step and indeed, no assets are generated at this stage. The later phase is the actual build step specific to mdx hosts like Next.js, Astro, etc., Jupyter Book and Quarto where the island-related conversion happens. As for the why, this workflow:

(1) enables extending an existing larger site where some pages are marimo-based and other pages are regular ones
(2) lets agents write marimo cells directly in MDX, MyST MD (for Jupyter Book) and QMD (for Quarto) without starting from an existing full notebook
(3) provides interactivity on the client-side through WASM (which also has its costs of course in terms of start time and package compatibility)

The only think I want is a good API to work with it.
[...]
One things that could be hard to get right here is caching [...] But caching is hard.

This is very much our focus currently. We are working on an export API which lets you precompute outputs over a variety of inputs and leverage recent work on caching to let you and/or your agent export notebook outputs into a no-WASM site with a high degree of customizability.

[banditburai]

Chiming in with my version of an ask aligned with this discussion: essentially I don't want to use the React frontend in any form (islands etc), but I still want the full strengths and value prop of the marimo backend stuff within my own custom apps.

I've been running marimo as a headless reactive backend with the frontend fully replaced: marimo edit --headless as a subprocess, driven over the wire, cell outputs streamed to the browser via SSE, all rendering server-side Python (no React, none of marimo's frontend bundle). It works well — the kernel/frontend separation in the architecture is genuinely clean. But everything I touch is private surface: the {"op": ..., "data": ...} WS envelope, the _messaging notification types (I decode with msgspec against a pinned version), and a few /api/kernel/* endpoints.

What would make this durable mostly already exists:

1. _schemas/generated/notifications.yaml is already generated and back-compat-checked in CI — blessing it as public, versioned API (like NotebookSessionV1 and the feat: hydrate islands from JSON payloads #9987 islands payload) would let external consumers pin and diff instead of reverse-engineering. Not asking for a frozen protocol, just published versioned schemas.
2. A supported "run the kernel headlessly and subscribe" mode without the bundled frontend.
3. Rich components as structured data: outputs are already MIME-typed but tables etc. arrive as text/html wrapping with JSON-in-attributes that only your frontend can render — exposing component name + props as data would mean no HTML parsing for custom frontends.

(anywidget gets suggested for custom UI, but it's the inverse problem — it embeds custom components inside marimo's frontend and reintroduces per-component JS. This is embedding marimo's kernel under a custom frontend, keeping everything Python.)

The nice part: this and the export API could share the same output schema — precomputed for static sites, streamed for live ones.