Tested out an idea quickly with Twilio, demoed an API in another notebook, and prototyped a new feature from my iPad while on an airplane (that's my favorite part).
It's been really useful for me and now that I can embed it into my blog posts or in the documentation is going to be really helpful for the rest of our team. Awesome work guys!
Even though your code blocks are separated, and text appears between them, it's all one contiguous block of code.
It has data visualization features, and it also manages npm packages for you, but those are just features. Another way to think of it is, a different (hopefully better) version of the thing you'd get if you just typed "node" in your terminal.
That means your embeds can write to the filesystem, use any npm package, (even spin up child processes if that's what you want to show off!).
The actual thing you are embedding is a version of our app, Tonic, which yes interfaces remotely with Node.js. I think this title is the best way of getting the idea across in a few words though.
var fs = require('fs');
var content = fs.readFileSync('/etc/passwd');
or look into any other file?
How do you specify npm dependencies. Does it "automagically" inspect your `require` statements?
Just take the frontend code and replace the remote backend with electron?
The idea here of course is that all those packages are usable (so for example if you want to show someone how to take files and zip them, you can). Additionally, it is important not to forget that a package can actually be 20 packages thanks to nested dependencies. A lot of work went into making a system that when you type require("package") works instantly and doesn't have to go and fetch the nested dependencies -- not only that, but shrink-wrapping in the background so that rerunning the notebook is 100% reproducible (not constantly changing underneath you as versions change). With this we also get the really cool ability to not only have every package on npm, but every version of every package. If you look at this example, you'll see we can easily compare two versions of the same package: https://tonicdev.com/tonic/api-diff-example
Runbook: provide support staff executable blocks they can modify to record how they are fixing a support fire.
API docs: show off that NPM package you built with real examples the user can modify by putting in their own data.
That's off the top of my head.