There's different tradeoffs of course, and we've obviously been inspired by iPython and Mathematica and other interactive programming environments. Tonic is in large part asking whether we can take the lessons of interactive programming and make them useful to broader software development (hence a focus for example on object viewers to analyze binary data). I think the features called out in the site are pretty unique, but perhaps some conceptual differences are warranted.
The key differences I would say are:
1. The fact that you have access to every NPM package. Node is now the environment with the most amount of packages, chances are someones solved part of your problem already, why not have all that code at your fingertips?
2. It was crucial in our mind to exactly match the behavior the code would have if you ran it through node as if it were a straight file. That means, for example, that every cell has to execute synchronously after the last (not async, you can't have ticks happen in between cells -- you're code will now behave dramatically differently if you download it, especially in an environment so dependency on asynchronous behavior like node). It really is like a living file: even hoisting works -- you'll notice that if you modify a function that is referenced in an earlier cell, Node will notify you that you've "changed" the past, and will rerun from that point. This is very different from the additive nature of iPython style repls where every cell stomps on top of the last. In Tonic, no code that has run isn't on the screen: because it really is like just running the file (again, you can download it and run it yourself).
3. Related to 1, notebooks are also easily publishable in a living way: a node notebook is just a node package. So you can require an notebook from any other notebook, instant sharing.
4. Our take on object viewers - we want these to be discoverable, not a part of the code, its a view on the results. Tonic fundamentally deals with Javascript objects, but the object viewers are applied on top -- post execution you can decide to look at an image as an image, or hex viewer, or download. An array could be a coordinate or a graph, both are available to you to switch between, not a function you call to display your data. We really want the tool to help you find new views on your data.
-- For 1, that's analogous to having every python package via pip/conda, and the same for other juypter langs.
-- For 2, this is scary/hard for traditional notebook usecases. IPython gives the user control, so there is no fear of beach balling & unintentional outside effects. I do appreciate the intent however :)
-- For 3, a notebook is just a json file and shareable. In fact, you can share a python notebook with a js app and it'd still work. With maybe 50loc, you can even keep the require syntax.
-- For 4, we're doing this within juypter just fine, and bokeh as well.
We recently went through a similar decision making process, and, when thinking about the above and more, decided it'd be better for the community for us to add features to Juypter than make yet another notebook. I don't think Juypter is the end-all (though for none of the reasons above), so I'm still confused here.
The key differences I would say are:
1. The fact that you have access to every NPM package. Node is now the environment with the most amount of packages, chances are someones solved part of your problem already, why not have all that code at your fingertips?
2. It was crucial in our mind to exactly match the behavior the code would have if you ran it through node as if it were a straight file. That means, for example, that every cell has to execute synchronously after the last (not async, you can't have ticks happen in between cells -- you're code will now behave dramatically differently if you download it, especially in an environment so dependency on asynchronous behavior like node). It really is like a living file: even hoisting works -- you'll notice that if you modify a function that is referenced in an earlier cell, Node will notify you that you've "changed" the past, and will rerun from that point. This is very different from the additive nature of iPython style repls where every cell stomps on top of the last. In Tonic, no code that has run isn't on the screen: because it really is like just running the file (again, you can download it and run it yourself).
3. Related to 1, notebooks are also easily publishable in a living way: a node notebook is just a node package. So you can require an notebook from any other notebook, instant sharing.
4. Our take on object viewers - we want these to be discoverable, not a part of the code, its a view on the results. Tonic fundamentally deals with Javascript objects, but the object viewers are applied on top -- post execution you can decide to look at an image as an image, or hex viewer, or download. An array could be a coordinate or a graph, both are available to you to switch between, not a function you call to display your data. We really want the tool to help you find new views on your data.