More than that. marimo.app runs in the browser with WASM. That makes for a snappy experience but is limited in RAM and what kinds of packages can be run. This runs Python on a traditional backend, letting you use any package and any more resources.
Thanks. marimo is cool, but spinning up N backends for scale would not be tenable cost wise.
Currently looks like there's this very cool full-frontend notebook tool: https://github.com/gzuidhof/starboard-notebook , which can be tied to a small backend to save/load python scripts from. This is working well for edu usecases potentially with support for both js and python.
Thanks! Notebooks on molab are public (but undiscoverable, like public GitHub gists), and can be shared with links. This is described here: https://marimo.io/blog/announcing-molab.
Is there anything you are doing to prevent these notebooks from being indexed by Google/etc? Gists will show up in google search results if they've been linked from anywhere that google happens to find. The robots.txt just has 'Allow: /'.
I have no experience with Marimo so I guess I don't know the security model here.
Sorry! Did the notebook not connect to the runtime? Notebooks usually start quickly but there is variance, which we are working to tighten. If you have a notebook link/ID, we can look into it.
Thanks for the kind words. Many of our users have switched entirely from Jupyter to marimo for experimentation (including the scientists at Stanford's SLAC alongside whom marimo was originally designed).
I have spent a lot of time in Jupyter notebooks for experimentation and research in a past life, and marimo's reactivity, built-in affordances for working with data (table viewer, database connections, and other interactive elements), lazy execution, and persistent caching make me far more productive when working with data, regardless of whether I am making an app-like thing.
But as the original developer of marimo I am obviously biased :) Thanks for using marimo!
I just like the Jupyter Lab overall IDE-like interface. It's really well designed for general random exploration, and works well with Wil McGugan's "Rich" console output library. On the other hand, it's not really at all well suited for building web application type stuff. It's capable of it (with a whole lotta "hackery" and jumping through hoops) but it's not really built for it the way Marimo is. Marimo just feels like the right choice once you want to build a real repeatable end-usery type application for day to day use on a specific task. The widget set seems really well designed in Marimo too. I'm also really pleased with Marimo's usage of the uv Python package tool as well. I fully intend to keep both Marimo and Jupyter within easy reach, as they're both really excellent at what they do.
marimo still allows you to run cells one at a time (and has many built-in UI elements for very rapid experimentation). But the distinction is that in marimo, running a cell runs the subtree rooted at it (or if you have enabled lazy execution, marks its descendants as stale), keeping code and outputs consistent while also facilitating very rapid experimentation. The subtree is determined by statically parsing code into a dependency graph on cells.
For those new to marimo, we have affordances for working with expensive (ML/AI/pyspark) notebooks too, including lazy execution that gives you guarantees on state without running automatically.
One small note: marimo was actually first launched publicly (on HN) in January 2024 [1]. Our first open-source release was in 2023 (a quiet soft launch). And we've been in development since 2022, in close consultation with Stanford scientists. We're used pretty broadly today :)
