Introducing marimo-studio

The marimo team released marimo-studio, an open-source tool that lets a single marimo notebook power multiple audience-specific frontends in any web framework while keeping views in separate files from the analysis. Studio prerenders each view's states at build time so it runs as static files on hosts like GitHub Pages with no Python runtime, and every number on a page traces back to the notebook cell that computed it. The package ships with example notebooks including quadratic_program.py, athletes.py, and occupancy.py, whose views are built with React, Reveal.js, Svelte, Mosaic, Three.js, and Observable Notebook Kit.

Introducing marimo-studio Build a view of your notebook for every audience, in any web framework, with every result traced back to the Python behind it. Your marimo notebook is where your computational work lives: the data, the definitions, and every assumption behind a result. Each audience you share it with has different needs and expects an experience tailored to them: a lecture for students, an article for readers, a dashboard for your team. Today we’re introducing marimo-studio https://github.com/marimo-team/marimo-studio , which gives each audience its own view of the notebook: - Any frontend. Each view is its own web project, in whatever framework you like. - Separate files. Views live next to the notebook, so coding agents build them without editing your analysis. - Traceable results. Every number on a page traces back to the notebook cell that computed it. - Prepared static exports. Studio prerenders a view’s states at build time, so it runs as static files on GitHub Pages or any host, with no Python runtime to load. Readers see the results and never the notebook source, which keeps sensitive work private. Copy this instruction for your coding agent to get started: Your agent reads the instructions Studio ships with the package, then builds a single notebook with the two requested views. Notebooks usually reach their audiences in one of two ways. The first is a copy of the notebook for each audience. The copies drift: a fix made in one never reaches the others, and the slides end up disagreeing with the article. The second is to put the presentation into the notebook, with HTML templates, CSS, and layout code in cells next to the calculations. The notebook gets harder to read and to review, because a font change and a formula change land in the same file. Coding agents make the second path more tempting. They write frontend code well, so a polished page is one request away. When the agent works inside the notebook, though, each design request also edits the file that holds your analysis. We wanted agents to take on the frontend work while the analysis stays put, so Studio keeps the two in separate files. Notebooks do all kinds of work. Some teach an idea, some dig through data, and some explain how a model behaves, and one notebook often has to serve several kinds of readers at once. With Studio, the same notebook serves every one of them. quadratic program.py https://github.com/marimo-team/marimo-studio/blob/72376de50eb89fe8372ad55f3b341cfb439be154/examples/quadratic program.py teaches quadratic programs, a kind of optimization problem. The same notebook becomes a slide deck for the lecture, an explainer to read at your own pace, and a lab where you drag a dial and watch the solution move. The deck runs on React and Reveal.js https://revealjs.com/ , the explainer is plain HTML, and the lab is a Svelte https://svelte.dev/ app. athletes.py https://github.com/marimo-team/marimo-studio/blob/72376de50eb89fe8372ad55f3b341cfb439be154/examples/athletes.py digs into the roster of the Rio 2016 Olympics. The same analysis opens as a report you can filter by sport, an explorer with linked charts, and a 3D tour of every athlete. The report is plain HTML, the explorer links its charts with Mosaic https://uwdata.github.io/mosaic/ , and the tour runs on Three.js https://threejs.org/ . occupancy.py https://github.com/marimo-team/marimo-studio/blob/72376de50eb89fe8372ad55f3b341cfb439be154/examples/occupancy.py predicts whether a room is occupied from its sensor readings. The same model shows up as a monitor of the room, a review where you move the decision threshold and watch the errors change, and a report you can download as a PDF. The monitor is an Observable Notebook Kit https://observablehq.com/notebook-kit/kit page, and the review and the report are React apps. The examples gallery https://marimo-team.github.io/marimo-studio/examples/ has more. Each view is an ordinary frontend project, saved as a folder next to the notebook. A coding agent works with its HTML, components, and build config the same way it would in any web project: Studio builds plain HTML, React, Svelte, and Observable Notebook Kit projects out of the box, and a provider API https://marimo-team.github.io/marimo-studio/reference/provider-api connects any other frontend project and its build command. Preview rebuilds on every save, so you can watch a view take shape and steer it as you go. Inside a view, two elements and one attribute reach into the notebook by name: | In the view | What the page gets | |---|---| | <marimo-cell element | A cell’s output, with live controls | | <marimo-output element | One object, even one the notebook never shows | | mo-value attribute, on any element | One value, as data for the page’s own code | Views can lean either way. The Explainer mostly places the notebook’s own cells, while the Lab reads values and draws nearly everything itself with Svelte and D3 https://d3js.org/ . Each figure and number a view shows comes from one named notebook cell. When you change a control in a view, marimo reruns the cells that depend on it and the view updates, so every view agrees with the notebook. The same link makes every result in a view auditable. Studio resolves each name to the cell that produces it, and marimo’s dataflow graph https://docs.marimo.io/guides/editor features/dataflow/ leads from that cell to the data, definitions, and assumptions behind it. A reviewer checks a number on the page by reading the Python that computes it, and marimo-studio validate reports any name a view uses that the notebook no longer defines. Values reach the page through standard DOM events. mo-value sets marimoValue on its element and dispatches marimo-value-updated each time the notebook recomputes the value, so any page can listen for it: The React and Svelte starters wrap the same events for you: React views get a useMarimoValue hook, and Svelte views a use:observeMarimoValue action. A view can be shared as a folder of static files on GitHub Pages or any other static host. You choose how the exported view runs. A browser export runs the notebook in each visitor’s browser with Pyodide https://pyodide.org/ , a build of Python for WebAssembly. A prepared export runs no Python at all, on a server or in the browser. Prepared exports are new, and marimo-export https://github.com/marimo-team/marimo-export powers them. Studio runs the notebook ahead of time for the control settings a view lists and saves each result as static files. Visitors move between those saved states, and the notebook source stays with you. Every view on this page is a prepared export. We’re excited to share more about the approach, and how it builds on marimo’s cell cache, in an upcoming post. When a notebook needs live Python, for example to read files on a server, use credentials, or call a service, marimo run serves the same view from a Python server. Python app frameworks such as Streamlit https://streamlit.io/ and Reflex https://reflex.dev/ let you build an interactive app by writing its interface in Python. Frontend-first tools such as Observable Framework https://observablehq.com/framework/ and Evidence https://evidence.dev/ start from the page, and pull in the data it needs from scripts or queries. Studio sits between an ordinary marimo notebook and the frontend ecosystem that already exists, and it turns the frontend-first order around. The notebook is the center. It holds the analytical context, the decisions and knowledge its author builds up: where the data comes from, how each number is defined, and which assumptions a model makes. Like a semantic layer, it defines what the numbers mean, and every view reads from it. Malloy https://github.com/malloydata/malloy and Malloyyo https://github.com/malloydata/malloyyo take a similar approach, with agents building dashboards over a semantic model written in Malloy. In Studio, the context lives in a marimo notebook written in Python and SQL, and views can use any frontend framework. This fits how coding agents already work. They write good Python in notebooks and good frontend code in web projects, and Studio lets them do each where it belongs, with no new app framework to learn. As agents make views inexpensive to build, the analytical context behind them is worth more, and Studio keeps that context in one notebook that grows with every change its author makes. The notebook behind every view is a regular marimo notebook, so everything built for marimo keeps working with it. It runs in a sandbox https://docs.marimo.io/guides/package management/sandboxes/ with its own dependencies, serves as an app, and pairs with your coding agent through marimo’s AI sidebar or marimo pair . marimo-lens https://marimo.io/blog/introducing-marimo-lens shows what this makes possible. Select part of a page, describe a change, and Lens hands your agent the selection, your note, and the notebook cells behind it. With Studio, Lens works in the notebook and in every view, so the agent can tell whether a change belongs in the view or in the notebook. In the recording, restyling a table changes only the view. Labeling the figure changes the notebook, and the label appears in both at once. Studio is available on PyPI as marimo-studio . The documentation https://marimo-team.github.io/marimo-studio/ walks through a first view https://marimo-team.github.io/marimo-studio/guide/getting-started , authoring with a coding agent https://marimo-team.github.io/marimo-studio/guide/coding-agents , and running or exporting a view https://marimo-team.github.io/marimo-studio/guide/run-and-share . If something breaks or you have an idea, please open an issue https://github.com/marimo-team/marimo-studio/issues . On a personal note, before I started developing marimo itself, I was a user developing with marimo. One of the things that drew me to it was that a notebook could also be an interactive web app. I still value that. But the more notebooks I wrote, the clearer the gap became between the interface I need as the author and the one the people reading my notebooks actually want to use. Studio is my answer. Each reader gets a page made for them, and the notebook stays the place where I work, a regular marimo notebook ready for whatever marimo adds next. I can throw away any view without throwing away the attention I invested in the analytical context that produces it.