The idea

The notebook should own the computation, controls, and decisions. A published view should own the presentation.

The idea was simple:

1. Author the analysis in a marimo notebook.
2. Create a Studio view from the notebook.
3. Use Quarto to present the view as a polished document.

To test the pipeline, I made a tiny notebook with a slider. The notebook computes the square of the selected number, and the Quarto view displays the result.

The first obstacle

The Quarto provider was available in the development version of marimo Studio, but installing that development package did not provide the browser assets needed by the Studio server. The editor started, but the browser returned an HTTP 500 because build-meta.json was missing.

The fix was to build Studio from its source repository. That required the JavaScript build toolchain in addition to the Python environment. The first build attempt used Node.js 26 and stopped because one of the frontend scripts still passed --experimental-transform-types, an option that Node 26 no longer accepts.

Fortunately, the source setup had also installed Node.js 24.19.0 in its Python environment. Running the build with that Node version produced the browser assets successfully.

A minimal notebook

The smallest useful test is a notebook with one control, one computation, and one displayed result:

import marimo

app = marimo.App()


@app.cell
def _():
    import marimo as mo

    rounds = mo.ui.slider(1, 100, value=10, label="Rounds")
    rounds
    return mo, rounds


@app.cell
def _(rounds):
    total = rounds.value**2
    return (total,)


@app.cell
def _(mo, rounds, total):
    mo.md(f"The square of **{rounds.value}** is **{total}**.")


if __name__ == "__main__":
    app.run()

Moving the slider to 36 changed the Quarto view to:

The square of 36 is 1296.

This small example tested the complete path rather than just checking that the editor opened.

Reproduce this setup

The original experiment required a local Studio source checkout and a frontend build. That was useful for understanding the missing browser assets, but it is no longer the recommended setup.

The current project uses a pinned Studio preview wheel that includes both the Quarto provider and the browser assets. The current setup instructions are in the repository README.md. They require only uv and Quarto in addition to Python.

The preview wheel is still not a stable release, so its version should be revisited when marimo Studio publishes the Quarto provider through its normal release channel.

What I learned

The difficult part was not Quarto itself. Quarto was already installed and could render the document. The friction came from using an unreleased Studio provider and therefore needing to build Studio’s browser assets locally.

The experiment also clarified the boundary between the tools:

• marimo owns the notebook and its reactive computation.
• Studio connects notebook results to named views.
• Quarto supplies the document structure and presentation.

This may become easier as marimo Studio matures. For now, I am treating the setup as an experiment rather than a final installation recipe. What mattered to me was seeing that a control in a marimo notebook could drive a polished Quarto view.

Next steps

The prototype is now committed in the site repository and uses a pinned, portable Studio preview wheel. The old blog will remain as an archive. Future writing will happen here.