Show HN: Marimo – an open-source reactive notebook for Python

Original Article ↗ Hacker News Discussion ↗

An open-source project called Marimo is positioning itself as a reactive, Python-based alternative to Jupyter notebooks, aiming to fix long-standing issues around hidden state, non-deterministic execution, and poor version control by storing notebooks as plain `.py` files and automatically tracking cell dependencies. Commenters are enthusiastic about its ability to blend exploratory work with easy app-style sharing, and appreciate features like a dependency graph, variable viewer, and planned integrations such as WASM, debugging, and linting/formatting tools. At the same time, they note trade-offs in flexibility, incomplete solutions for fully reproducible environments and package management, some state-tracking edge cases, and rough edges in editor integration that will need to mature.

Positioning vs Existing Tools

  • Seen as an alternative to Jupyter/Pluto/Observable, with reactive cells and a pure-.py file format.
  • Many want clearer, top-level “Jupyter vs Marimo” messaging on the site, not just in the FAQ.
  • Compared to Streamlit: Marimo supports classic notebook-style exploration first, then export to shareable apps.
  • Quarto is mentioned as solving some reproducibility issues, but Marimo’s synchronized reactive cells are highlighted as the main differentiator.

Reactivity, State, and Reproducibility

  • Main appeal: removes hidden state by topologically ordering cells via a dependency DAG and re-running affected cells on changes.
  • Users like that this improves determinism and makes notebooks easier to reason about and review (since they’re plain Python).
  • Some find it less flexible: they sometimes want to tweak a cell without triggering downstream recomputation.
  • State tracking isn’t perfect: mutations like d.x = "new value" on a dataclass don’t currently cause dependent cells to re-run.

Packaging and Environments

  • Many consider package/env capture “the other half” of reproducibility and want notebooks to embed dependency info.
  • Marimo has “package management for reproducible notebooks” on its roadmap but no concrete design yet.
  • Discussion of pip freeze workflows notes issues: non-pip installs, platform-specific variants, bloated/obsolete deps, and manual maintenance.
  • Alternatives like Poetry, pip-tools, and Nix are mentioned; opinions differ on how painful Python packaging really is.

Deployment, WASM, and Apps

  • There is active interest in a JupyterLite-style WASM/pyodide mode for in-browser execution, MDX/Nextcloud embedding, and “standalone HTML” apps.
  • WASM support is explicitly on the roadmap; current docs embedding uses iframes.
  • Users like that notebooks can be turned into simple web apps, suitable for internal tools and interactive tutorials.

Editor Integration and UX

  • A VS Code extension exists but currently opens a full browser UI rather than using VS Code’s native notebook interface; some find onboarding confusing.
  • Questions about editing .py notebooks in an external editor and seeing live updates; this is desired but not yet supported.
  • Users ask about long-running background tasks that survive closing the tab; current behavior is unclear.

Plugins, Widgets, and Features

  • Internal widget system uses custom elements; there’s no public plugin API yet, but one is planned.
  • The tool is built from scratch and does not depend on Jupyter or IPython; Jupyter-widget compatibility is only an idea for now.
  • Existing features include a dependency-graph viewer, variable viewer, Copilot integration, and plans for PDB-based debugging and better graph visualization.
  • Requests include: mermaid diagrams in markdown, RStudio-style doc-aware completions (claimed to exist), better GitHub previews, cell-level caching, and more nuanced variable scoping (e.g., for repeated plotting code).