Hacker News Reader

Comment by stared | Hacker News Reader

I have found it surprising that there was no JavaScript no-backend notebook. Tools used either Python-based Jupyter (fine, but perverse: why JS -> Python -> JS), Node (e.g. RunKit), a complex superset of JS (e.g. ObservableHQ), were like JSFiddles (sandboxes, not notebooks), or are on-offs (e.g. in Eloquent JavaScript).

Thanks for creating StarBoard - it was, as is, needed!

View on HN

I think one of the main reasons was the lack of dynamic import support until fairly recently [0], being able to import code dynamically without crazy <script> hacks is very useful in a notebook. The tools you mentioned all pre-date that I think.

Secondly notebooks have to run sandboxed. Most notebooks run the output/code in an iframe but the editor is in the main window (e.g. JSFiddle). The moment you do that you can no longer support notebook style output (cell-output-cell-output) without some serialization step as you can only embed the iframe in one place (so there would be a single output pane). This is also how Project Iodide worked [1].

Starboard's approach is to put the entire editor/runtime in the sandbox which I think is a superior approach for a notebook. It only talks to the outside frame over a thin API (for saving notebooks, refreshing, syncing the content).

[0]: https://caniuse.com/es6-module-dynamic-import [1]: https://alpha.iodide.io/

Mike Bostock, the creator of the visualization language D3, also created a javascript notebook product called Observable [1].

I like the idea of doing everything in the same language, but I can't give up the python scientific computing environment to switch to javascript.

[1] https://observablehq.com/product

Reply on news.ycombinator.com