3 ms·
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)
by stared 6y ago
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!
- protoduction 6y agoI 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 https://caniuse.com/es6-module-dynamic-import [1]: https://alpha.iodide.io/ https://alpha.iodide.io/
- maliker 6y agoMike 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 https://observablehq.com/product