Similar project: Starboard

[gzuidhof]

Hi Jeremy,

I came across this repo when exploring the rabbit hole that is alternative notebook projects. I'm building a notebook system, not based on Jupyter, that runs entirely in the browser by design and is entirely static (like p5-notebook). I recreated the P5 example notebook here, here it is entirely statically which you could embed anywhere.

One cool thing is that there is no one 'kernel' and no 'magic' (it's all just JS), so you can really mix different languages. Also you can "build the ship as you sail", similar to Jyve. You can even write P5 code in Python through pyodide if you want :). The homepage has some more details, it's open source here.

Curious to hear your thoughts and happy to bounce ideas!

[jtpio]

Hi!

Thanks for sharing, Starboard looks really good and polished!

There is really a need and story for having lightweight and static interfaces running Python code (and other languages) in the browser instantly. Really nice to see some activity around this and different ways to explore this space.

Just curious: did you try building the notebook interface using existing components JupyterLab (or maybe nteract) in the beginning? Or went directly with a custom implementation?

It looks like Starboard also provides a plugin system, so other languages can be added? (for example https://github.com/gzuidhof/starboard-python)

One of the main goal of the p5 notebook is to reuse as many components, protocols, and concepts from the Jupyter ecosystem. And build a custom notebook interface with the "Jupyter look and feel". Which is why it still mentions "kernels" and "magics" so Jupyter users find the interface familiar.
And then make that approach more generic so it can be used for other languages too, still as a static bundle running in the browser.

[gzuidhof]

Thank you for the kind words!

I definitely considered starting from Jupyter - but I figured that there were so many parts that are just not required (e.g. talking to the kernel over a protocol) when everything is in the browser, as well as bits that are probably missing (defining new cell types at runtime and other plugins). I guess an analogy would be trying to retrofit a car to be a locomotive (maybe you disagree! I am not familiar enough to say this).

I also needed fine control into the content: Starboard is designed to run in an iframe for sandboxing, but should still "feel as one" with the outside frame (starboard.gg is an example of this, the notebooks run in an iframe on a different domain).

Also.. not unimportant: I'm not familiar with Jupyter's internals, so it would have been hard to adapt it for me.

So I decided: I'll build Starboard to be Jupyter as it would've been if it was designed to be in-browser first.

Most editors and in-browsers REPL take a different approach (p5 notebook also from what I can tell): there is an iframe in which your code gets run, instead of the whole editor running in the sandbox. In Starboard having a single sandbox allows you to script the editor on the fly as well as use "normal" HTML and CSS for everything - there's less need for magic. An example problematic case for separate iframes for sandboxing: You have one JS runtime (in an iframe), but you have two HTML elements you want to show in between different cells - it's not possible with iframes as you can't split it up!

I wrote up this example just now to illustrate it: it compiles CoffeeScript and displays the compiled JS code. It hopefully shows that it's pretty easy to add new languages, even dynamically :). (I did find out a minor bug I can now fix: once registered and you change the definition any existing cells don't update to the new handler, to do!)

With ES6 modules/imports it becomes really possible to dynamically import code, and almost by definition it will keep working: you point at one version (by URL) and unless there's a breaking change in browsers it should work forever. You can share a link, and it just works - that's the goal at least :)

Sorry for the small brain dump, just excited to share why I made some decisions :)

[jtpio]

Thanks a lot for this write-up! It is very useful to learn what other folks think about notebooks and what they should be or become.

but I figured that there were so many parts that are just not required (e.g. talking to the kernel over a protocol) when everything is in the browser, as well as bits that are probably missing (defining new cell types at runtime and other plugins). I guess an analogy would be trying to retrofit a car to be a locomotive (maybe you disagree! I am not familiar enough to say this).

So I decided: I'll build Starboard to be Jupyter as it would've been if it was designed to be in-browser first.

This is a very valid point, and the whole in-browser idea raises the question of whether some parts could be simplified. Especially since there is no real server anymore.

Maybe there is still value in having the in-browser version follow the Jupyter standard and protocol though, since this has been one of the major strength of the Jupyter ecosystem over the years.

With ES6 modules/imports it becomes really possible to dynamically import code, and almost by definition it will keep working: you point at one version (by URL) and unless there's a breaking change in browsers it should work forever. You can share a link, and it just works - that's the goal at least :)

That's definitely one of the main advantages of this setup, and is really exciting!