Looks nice for low cost workloads. I’ve thought about creating something like this, but the more I’ve used Jupiter notebooks for AI/ML, the more I’ve come to appreciate that non-reactive cells are preferable for that use case, despite the lack of enforced consistency. When it takes minutes or hours to run a cell, you really don’t want the runtime automatically running anything.
Using the .py extension and storing cell outputs separately is a nice improvement, though.
marimo has some features to prevent automatic execution for high compute workloads. For example, you can selectively disable cells and their descendants: https://docs.marimo.io/faq.html#faq-expensive
I know one of the cofounders of the project, it’s cool to see it posted here 🙂
Looks very cool, although this seems closer to a (cleaner/more intuitive) Streamlit alternative than a better python notebook.
What makes this better than Jupyter?
Reactivity, essentially. It takes notebook-style calculations in the direction of Excel spreadsheets (but better). You move a slider and all dependent cells get recomputed. Authors cite Pluto.jl as one of their biggest inspirations.
That’s cool, thanks for answering
developer-friendly: pure Python git-friendly file format (.py), GitHub Copilot, fast autocomplete, code formatting, and more
I’ve had to spend some time maintaining a set of Jupyter Notebooks, so Marimo seemingly focusing on “developer-friendliness” is very appealing. The developer experience with Jupyter Notebooks can be full of papercuts:
The ability to use standard python tooling for Marimo notebooks is a big plus. Though I wonder what they’ll do if they ever want to scale Marimo beyond Python, and have it run code in other languages too.
How does marimo handle ordering of the cells, reordering, and markdown only cells? I’m quite keen to switch away from jupyter and marimo does look appealing.
Cells are stored in the notebook file in the same order they are arranged in the notebook UI. The execution order of cells however is determined by tracking definitions/references of global variables across cells, so the visual ordering of the cells is decoupled from execution order.
There are no markdown-only cells. You create markdown with a library function, mo.md(). This has the advantage of allowing you to dynamically create markdown and interpolate Python values (plots, marimo’s UI elements, …) into your markdown. In the future we may add a UI for a WISYWIG markdown-only cell that generates a Python cell calling mo.md() behind-the-scenes.
This is pretty cool!
Similar to clojure’s clerk - https://px23.clerk.vision/ , but they seem to have different target audiences and as such are making different trade-offs.
Interesting that they both appeared at about the same time, I guess growth in the popularity of notebooks bundled with issues created by notebooks creates a solution vacuum that needs to be filled.
Didn’t spot any mention of how the on disk format looks, so posting here:
def __(bars, mo, scatter):
chart = mo.ui.altair_chart(scatter & bars)
from https://github.com/marimo-team/marimo/blob/main/examples/reactive_plots.py .
I really like how simple this is, each cell is a function that gets global variables as inputs and produces global variables as outputs.