I’m glad these concerns are becoming more widespread, since they are somewhat subtle and when we originally shipped RunKit many people didn’t know why we didn’t “just write a js backend for Jupyter”. The reality is that solving these problems are a huge engineering challenge and we spent the entire first year of development at RunKit on unifying the “module” and “REPL” environments. Our litmus test was that notebooks would be logical to work with once they could literally be required by other packages as if they were just modules with no modifications. The solution we came up with was VM-level time traveling: if you modify a previous cell, you should rewind the entire state of the machine (including undoing changes made to the file system, spawned processes, etc) and “pick up from there”. In RunKit, if cell 3 deletes a file, you can still read the file if you modify cell 2, since we snapshot the entire computer, and thus you don’t have to “pretend” you’re modifying cell order like with Jupyter. In this way you really do get the best of both worlds: a notebook never has out of order cells or is displaying its contents in an unintuitive way because if behaves “as if” you had just rerun the entire notebook from the start on every change - but with the feel and speed of iteratively appending cells. Additionally, since this isn’t done at the “language level”, computer-level side effects don’t become “out of sync” with your notebook - “oops I dropped a table in the database” - don’t worry just rerun the cell with corrected contents, it’ll always run with the same state it started with. You can read more about this in a blog post we wrote when we initially released (even though it reads like a direct response to slide 25 of this presentation): https://blog.runkit.com/2015/09/10/time-traveling-in-node-js...