Hi -- author here. I just presented this work at JupyterCon 2023 so I figured it was time to advertise more broadly. There are a few rough edges but my hope is that, by making all the reactive behavior opt-in and only enabled for in-order execution (i.e., cells above the one I execute will never reactively execute by default), it can be predictable enough to be useful in practice.

There's still a long way to go to get e.g. full dataflow understanding of all the common libraries, understanding file paths, autoreload integration, etc., but after nearly 3 years of on-and-off development I think it's finally useable-ish.

Looks like it solves a common problem but the page is a bit confusing. It could make it clearer upfront what it does (I didn't know what reactive meant in this context) and how it relates to Jupyter (I thought it was official/core stuff at first, but I take it its a third party tool that integrates into jupyter).

Stuff like "Trust me? Good." in the introduction doesn't really help me answer "wtf does this do" more quickly and the first intro sentence is pretty long and convoluted.

I believe this is what Pluto sets out to do for Julia.

I used it as part of the “Computational Thinking” with Julia course a year or two back. Even then the beta software was very good and some of the demos the Pluto dev showed were nothing short of amazing

https://plutojl.org/

Nice! From what I've gathered this has been in the works for a while(?)

Thoughts ...

1. Yea, the Readme could do with a bit of polish. Your hero feature, AFAIU, is the automatic reactivity. This is in your second GIF, put this front and center and make it really clear what is happening. You (and I) know what reactivity looks like so we know what to look for, but someone new to the idea in notebooks could easily blink and miss this. I'd work on a nicer GIF and even a little youtube video just to make it really clear what's going on here. Bostock and ObservableHQ advertised their reactivity a while ago, you might be able to get inspiration for how they demonstrated it?

2. The syntax extensions are cool! Integration with ipywidgets is Ace!!

3. Do you have any comments on how ObservableHQ (Javascript runtime by Bostock) and Pluto (inspired by previous) informed or inspired your choices and implementation here? Is this basically the same for python/jupyter as those are for JS/Julia?

4. Annoying Questions or feature requests ... Are there any overheads? Any timeout facilities for long running code? Can the full variable and/or cell dependency graph be surfaced and visualised (ObservableHQ put this into the UI a while back and it was kinda cool).

Otherwise ... awesome to see this land! Congratulations!!!

I love Jupyter notebooks I just wish they looked as good as observable notebooks[1], not just in the overall layout but the charts/graphs you could make in general (plotly, matplotlib, etc don't even come close to d3.js, Observable Plot, etc)... I don't know why there seems to be a hole in the Python ecosystem for good designers or something

This seems to be a step in the right direction with reactivity though. But it's not instant like Observable notebooks. But still good

[1] https://observablehq.com

Now I wonder why this isn't an option in plain Jupyter. Inconsistent cell states and having to re-execute all cells after a single line change slows me down a lot.

Like I get why this doesn't need to be default, but this seems crucial enough to warrant being included in the base package.

Very cool. This project addresses some usability challenges that the Jupyter community has been debating and struggling with for years:

https://twitter.com/jakevdp/status/935178916490223616

My favorite take on this subject is Joel Grus' talk from JupyterCon 2018 (title: "I don't like notebooks").

https://conferences.oreilly.com/jupyter/jup-ny/public/schedu...

Slides:

https://docs.google.com/presentation/d/1n2RlMdmv1p25Xy5thJUh...

What's the correlation between people who don't use debuggers and people who use notebooks? I can't imagine writing code without a visual debugger, one at a level of pycharm. I think people who use notebooks must either be very active how they write code (don't misremeber variables, complexity of arrays, dicts etc) or have other means of debugging (print? Jupyterlab debugger? pbd?).

I love notebooks for their ability to preload chunks of code/data and have the ability to explore without delay. But having to put mental strain in keeping track of objects is too much for me. Vscode and pycharm have made strides in unifying the experience but it's still very much sub par, at least in my experience. Matlab-like style of executing code with possibility of reusing same debugger solution was perfect.

I spend a good deal of time teaching my students inside of Jupyter.

For Pandas, many problems can be solved by chaining (debugging as you go), converting the chain to a function, and placing the function at the top of the notebook after you load the raw data.

I get the problem this is solving, but adding some congrats and practical software engineering makes for much better notebook experiences.

I think it is a great idea, but doesn't apply to 99% of my notebooks because they need to run up to 2 hours to completely execute once, due to data intensive tasks. I usually run all cells once per day, up to cell x (where I left the day before), then continue working by adding cells and updating the state manually until I make progress (=no errors or output is as expected) and move on to the next cell - without re-executing other cells because this would be a productivity nightmare.

I kind of think quarto is a much better solution to the problems that notebooks try to solve plus you get the added bonus of having plain text as the file source.

Can you explain a little more about how it works? Does it handle cases like loops correctly (or self-referencing cells)?

Is this running a CPython fork, or how does the lineage tracking work? Are the values “x” and “y” in the quickstart example still simple Python int types, or are they a wrapped type?

The papers seem very interesting but even as an early adopter of tools like this I’d like to know what the limits and expectations are, and some docs would really help.

Congratulations! I starred it a long time ago but never used it (sorry). But I do think this IS the way to go for Jupyter. I don't know how I could contribute to this - lack of time, but mostly knowledge, but I would love to find other ways to help.

Reminds me of this project from Stitch Fix from years ago -- https://github.com/stitchfix/nodebook. Ahead of it's time I guess..

Reactivity is great. Is there any framework for using it without a REPL?

I.e. to define a DAG of tasks and have them executed as needed? I know existing workflow engines, and they are typically not reactive but rather work on batches.

How closely tied is this to Python? The need for reactivity is what drove the development for Pluto.jl, but it would be nice to have something like this for IJulia.jl as well.

How closely tied is this to Python? The need for reactivity is what drove the development for Pluto.jl, but it would be nice to have something like this for IJulia.jl as well.

That’s a pretty nice idea. The problem of knowing what state has been invalidated often drives me away from using a notebook. So it is nice to see this solved.

Looks quite neat.

I'm getting the habit of regularly restart the kernel and re-run everything - just to make sure everything works as expected.