When your powers combine

[rgbkrk]

I'm dealing with an internal struggle right now. There are at least 3 Jupyter kernels for node.

• IJavaScript
• Jupyter-nodejs
• Jove

For IJavaScript, Nicolas Riesco extracted the messaging protocol to a separate package (https://github.com/n-riesco/jmp) so it could be used by other node applications (Electron and Atom apps e.g.). My current preference is IJavaScript because I've been using it, liked the layout, the documentation, the installation process, etc.

The juptyer-nodejs package has wonderful magics and I know you (@jaredly) as an active member of the community.

I'm torn because I'd like to refer to one kernel for Node, especially if any of them were to go up on https://try.jupyter.org.

Where do you think the differences are? What would help foster a common set of packages amongst developers?

/cc @n-riesco

[jaredly]

First impressions of IJavascript

What does IJavascript have that jupyter-node doesn't have?

• incredible documentation
• shift-tab completion
• wait-for-async behavior
• messaging protocol in a separate module (great idea btw)

What does jupyter-node have the ijavascript doesn't have?

• %%coffeescript, %%babel, %%clojurescript magics (setup extensibly)
• !echo "shell commandable" arbitrary shell commands (mimicking ipython), and cd somedir to change directory (I not positive ijavascript doesn't have this, but it appears so)
• tests

The only other difference I see is IJavascript's use of $$magic$$ variables. jupyter-node on the other hand uses a display() function (modeled after ipython's display() function) that can be invoked two ways:

• display(something), and it will be automatically determined how to show it (this is not yet very clever)
• display(something, mimetype or "stderr/out") for example display(pngdata, 'image/png')

I find this more flexible than the global magic variable route, for a couple of reasons:

• display() can be called anywhere, and multiple times. $$png$$ can only be set once per execution block
• display() allows for the addition of further mime-types without having to remember more global variable names
• display() can also stream data, e.g. display("error", "stderr")

[ricardofbarros]

One of the biggest plus of IJavascript is the wait-for-async behavior

[jaredly]

@ricardofbarros my plan for that is, if the final expression evaluates to a promise, then wait for that promise to fulfill.
How does that sound?

[ricardofbarros]

That sounds awesome!

[n-riesco]

Hi everyone (and thanks to Kyle for the CC),

I've just checked jupyter-node out and I think a comparison in terms of features would be unfair (the development seems to have started only recently and I'm sure any missing features could be easily added).

My impression is that jupyter-node is closer in philosophy to ijs. Both make heavy use of %%magics, whereas IJavascript aims at making everything possible in Javascript (by means of $$global$$ properties; to demonstrate this, I'm currently working on a tutorial that produces animated graphs).

The other major difference is that both jupyter-node and ijs use sandboxes. This means that whereas all the Node.js features are accessible from IJavascript, some of these features are missing in jupyter-node and ijs.

And last, a few minor corrections about what IJavascript doesn't have:

• it is possible to run coffee-script (by installing the corresponding npm package); here's an example

  require("coffee-script").eval("if Math.random() >= 0.5 then 'head' else 'tail'");

• it is possible to run shell commands (again via Node.js)

  require("child_process").execSync("ls");

• $$done$$(something) in IJavascript does the same as display(something) in jupyter-node (for more complex formats, globals like $$jpg$$ and $$svg$$ are really convenient)

---

To answer Kyle's original issue:

I would be open to combine efforts at some point in the future, but I feel it's too early to make such a decision. I would like to explore how far I can take the idea of using only Javascript to provide %%magics and extensions. The other open question is: sandboxes vs real Node.js sessions.

PS: Kyle, I'm sorry I imagine the above doesn't solve your problem of what goes up on https://try.jupyter.org/

[jaredly]

@n-riesco I think "heavy use of %%magics" is a bit exaggerated; the magics are fun, and allow the processing of languages other than straight javascript in a way that's usable for more than toy examples (string concat get's a little old if you're actually writing code), but if you want to do things in just javascript, you don't need any %magic.

As far as sandboxing goes -- I don't know that that is necessarily a breaking point either -- it could be trivially changed in either of our projects (switch from vm.eval to eval or vice-versa)

I'd be interested in more info about what features are missing when using a sandbox.

[n-riesco]

Agreed, scratch heavy, let's just say it uses %%magics to accomplish tasks that could be accomplished in Javascript.

About the sandbox: switching to eval doesn't solve the problem. IJavascript is using https://github.com/n-riesco/simple-sm

I didn't test jupyter-node's sandbox thoroughly. I remember that global and setTimeout didn't work, for instance.

[jaredly]

@n-riesco simple-sm looks like a cool solution! sandboxes certainly have issues. I might well switch

[n-riesco]

Hi Jared,

I'm afraid I hadn't kept the repository simple-sm updated. I've just fixed that. This morning I merged the latest changes from IJavascript.

Also I was concerned the name was too ambiguous; I've renamed it as nel.

Hope this helps,

Nico

[ellisonbg]

I think it would be very advantageous to have a single, well maintained nodejs kernel :)

[okdistribute]

@jaredly, what is the rubric for deciding which functions go into the sandbox and which don't?