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
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.
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:
Most linters and formatters don’t support Jupyter Notebooks. In Python-land, ruff and black provide some support out of the box. And nbqa bridges the gap for some of the other Python tools. But that fails to account for all the other languages you can write in a Jupyter Notebook.
They aren’t friendly to version control:
Running a Jupyter Notebook leaves a bunch of junk behind
The output of every command
Tons of metadata (execution details for each cell, some of the view state of the notebook, editor/plugin specific metadata, etc…)
Can be non-trivial to run a formatter on the code in the notebook.
You may need to run a JSON formatter on the notebook file (.ipynb) itself. (God-forbid someone manually edit the notebook).
They aren’t test friendly. There doesn’t seem to be a canonical way to unit test the code in a notebook, or do some form of “acceptance” tests for the output of the entire notebook. I know projects like nbdev and testbook tackle this in different ways, but there still seem to be gaps in “the testing story”. I ended up needing to roll my own solution (pytest plugin) when I dealt with this.
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.
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:
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
- https://docs.marimo.io/
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:
.ipynb) itself. (God-forbid someone manually edit the notebook).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 callingmo.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:
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.