Feedback on reactivity
@Akshay As you can see in another thread, I'm really enthousiastic about Marimo and impressed with your work, and I'm on a path to explore much more of it, and to advertise it to my users.
But I still think that the way you communicate the promise of Marimo is not quite correct: the execution order simply is not predictable. As you say yourself, it is intentionally unspecified. Imho it is better to be upfront with that in the docs.
Quite a bit of may work in notebooks has nothing to do with widgets, I just want to run cells individually to see what happens, how long it takes, and so on. But: widgets are attractive, and Marimo's technique of binding widgets by value to a global variable is elegant.
Now, when I have a big notebook, where I want to work plain-dumb iteratively, but end up with a widget, it would be nice if I could mark some cells as reactive. On the assumption that Marimo' works its magic on the reactive cells only. And indicate which cells are reactive by means of special formatting (a different border, or something like that).
You have the mechanism to disable cells, so I could disable all cells, and only enable a few. But
* in a long notebook it gets cumbersome to disable every new cell that I write
* disabled cells cannot be run , not even manually
I would like to have neutral cells, that can be run, but are not subject to the typical Marimo dependency constraints.
It would make Marimo multi-paradigm. If you keep Marimo single-paradigm (i.e. reactive only) (which I totally can understand) then Marimo is not a competitor of Jupyter, but an optimization of it for a special use case: app-like notebooks. (and a very interesting and useful one at that).
1 Reply
@Dirk — we really appreciate your enthusiasm. Your passion is contagious! Thanks so much for taking the time to write such thoughtful feedback.
We can clarify the execution order in the documentation. The execution order of cells that are not comparable (in the set theoretical sense) is not specified. This is typical of dataflow execution engines, but I see now not obvious from our documentation.
We may be able to extend disabled cells to being executable — there is some extra work that we'd need to do in order to communicate the state of the notebook to the user in that case, which is why it wasn't supported in the first implementation (if you run a cell that has stale inputs, it should be still be stale).
We do not plan to make reactivity configurable at the moment, though perhaps something can be done in the future via an extension to or variant of disabled cells, as you suggest. You may also want to see IPyFlow, a reactive kernel for Jupyter that is more in line with what you suggest: https://github.com/ipyflow/ipyflow. It has some drawbacks, however, because it uses runtime tracing to figure out the DAG.
Even it its current state, however, I do believe that marimo can be used as a substitute for Jupyter notebooks. Many of our users have switched over from Jupyter to marimo entirely — including scientists at a national lab, researchers in academia, and developers at tech companies. We know this because that's what they tell us. And it's not just marimo: dataflow notebooks such as Pluto.jl, Observable, and Hex.tech have also found utility as a replacement for Jupyter in many individuals workflows. Some of these notebooks don't even have an app mode. There was an interesting article about this in Nature magazine three or four years ago.
In the end, though, we appreciate that for some folks, reactive notebooks are just at odds with how they use notebooks — and that's okay with us!
I am happy to continue this conversation, but let's move it to the #feedback channel. This channel is for folks seeking basic help with using marimo.