p5 notebook

[jtpio]

Hey folks,

Really cool stuff here. Just a quick post to let you know that I've recently been experimenting with similar ideas to build a notebook interface for p5.js: https://github.com/jtpio/p5-notebook

The approach is similar (using IFrames for the kernel), with slight differences:

• the p5 notebook is a custom frontend built using lab components, started from the notebook example in core lab
• it also uses its own (incomplete) "Jupyter Server in the browser", since the goal would be to eventually store and manage notebooks in the browser (for example using localStorage), manage kernels, and to some extent cover most of the notebook server API.
• the focus is to build a very minimal notebook UI for p5.js users, kind of similar to this proof of concept but giving it a "Jupyter look": https://github.com/aparrish/nb5js-proof-of-concept. Also with the idea of having something similar to the p5 online editor but for notebooks, that runs entirely in the browser.
• for now it inlines IFrames in the cell outputs to make it look like a real output. Although technically these other IFrames are copies of the real one used by the kernel. Each time a cell is executed in the main kernel, it is also executed in the other IFrames (they act as "views").
• most of this is not really specific to p5 and could be extracted into separate packages, a bit like what jyve does. But for now having it all in one place makes it easier to iterate on.

Anyway I just wanted to share this so that we can try to make all of this work together at some point!

[bollwyvl]

Cool, thanks for the heads-up. We should definitely figure out how to work the concept of browser kernels, which understand the full kernel spec, into a lab core PR... I've found it challenging to keep the API up properly, and there's a lot it could offer. I've also been percolating on how to get frontend language servers into jupyterlab-lsp, as well... And having that with p5 would be helpful, no doubt. The iframe approach is a great jump start... But eventually i think this kind of work will need a way to move into a worker. Even loading Pyodide, which is still the brass ring jyve is striving for, can definitely be taxing. I have toyed with doing a bespoke frontend (e.g start with a text box and a Jyve kernel, and build UI from there), but eventually the thought tends towards features that lab just already has. I think there's a lot of space for theme-only reduction and plugin replacement to get to more pleasing minimalism, such that other peoples' plugins just work. Maybe the best hook for that right now is probably "presentation mode"?

…

On Mon, Mar 23, 2020, 10:40 Jeremy Tuloup ***@***.***> wrote: Hey folks, Really cool stuff here. Just a quick post to let you know that I've recently been experimenting with similar ideas to build a notebook interface for p5.js: https://github.com/jtpio/p5-notebook The approach is similar (using IFrames for the kernel), with slight differences: - the p5 notebook is a custom frontend built using lab components, started from the notebook example in core lab <https://github.com/jupyterlab/jupyterlab/tree/master/examples/notebook> - it also uses its own (incomplete) "Jupyter Server in the browser", since the goal would be to eventually store and manage notebooks in the browser (for example using localStorage), manage kernels, and to some extent cover most of the notebook server API. - the focus is to build a very minimal notebook UI for p5.js users, kind of similar to this proof of concept but giving it a "Jupyter look": https://github.com/aparrish/nb5js-proof-of-concept. Also with the idea of having something similar to the p5 online editor <https://editor.p5js.org/> but for notebooks, that runs entirely in the browser. - for now it inlines IFrames in the cell outputs to make it look like a real output. Although technically these other IFrames are copies of the real one used by the kernel. Each time a cell is executed in the main kernel, it is also executed in the other IFrames (they act as "views"). - most of this is not really specific to p5 and could be extracted into separate packages, a bit like what jyve does. But for now having it all in one place makes it easier to iterate on. Anyway I just wanted to share this so that we can try to make all of this work together at some point! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#45>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALCRDSZWOPPYQJRH2MV3LRI5YEHANCNFSM4LR5PSBA> .

[bollwyvl]

Also on the file system: my original goal for jyve was to support dat or ipfs, and indeed I got a demo working in the beaker browser, back when it supported both stacks. The nice thing about these is that they would provide an ideal mechanism to serve both the "host" application (jyve, p5n, etc) as well as user data... Once you hit "publish" and get that hash, you could easily share your app/content, and with day, you could even update it, and subscribers would be notified. Since then, both APIs have been rounded out a lot, and we did a pretty cool demo with jupyterlab-dat for a sort of "notecast". This also provided a chat-per-dat, built as a bespoke notebook/servicemanager, which could be used to share additional notebooks.

…

On Mon, Mar 23, 2020, 16:36 Nicholas Bollweg ***@***.***> wrote: Cool, thanks for the heads-up. We should definitely figure out how to work the concept of browser kernels, which understand the full kernel spec, into a lab core PR... I've found it challenging to keep the API up properly, and there's a lot it could offer. I've also been percolating on how to get frontend language servers into jupyterlab-lsp, as well... And having that with p5 would be helpful, no doubt. The iframe approach is a great jump start... But eventually i think this kind of work will need a way to move into a worker. Even loading Pyodide, which is still the brass ring jyve is striving for, can definitely be taxing. I have toyed with doing a bespoke frontend (e.g start with a text box and a Jyve kernel, and build UI from there), but eventually the thought tends towards features that lab just already has. I think there's a lot of space for theme-only reduction and plugin replacement to get to more pleasing minimalism, such that other peoples' plugins just work. Maybe the best hook for that right now is probably "presentation mode"? On Mon, Mar 23, 2020, 10:40 Jeremy Tuloup ***@***.***> wrote: > Hey folks, > > Really cool stuff here. Just a quick post to let you know that I've > recently been experimenting with similar ideas to build a notebook > interface for p5.js: https://github.com/jtpio/p5-notebook > > The approach is similar (using IFrames for the kernel), with slight > differences: > > - the p5 notebook is a custom frontend built using lab components, > started from the notebook example in core lab > <https://github.com/jupyterlab/jupyterlab/tree/master/examples/notebook> > - it also uses its own (incomplete) "Jupyter Server in the browser", > since the goal would be to eventually store and manage notebooks in the > browser (for example using localStorage), manage kernels, and to some > extent cover most of the notebook server API. > - the focus is to build a very minimal notebook UI for p5.js users, > kind of similar to this proof of concept but giving it a "Jupyter look": > https://github.com/aparrish/nb5js-proof-of-concept. Also with the > idea of having something similar to the p5 online editor > <https://editor.p5js.org/> but for notebooks, that runs entirely in > the browser. > - for now it inlines IFrames in the cell outputs to make it look like > a real output. Although technically these other IFrames are copies of the > real one used by the kernel. Each time a cell is executed in the main > kernel, it is also executed in the other IFrames (they act as "views"). > - most of this is not really specific to p5 and could be extracted > into separate packages, a bit like what jyve does. But for now having it > all in one place makes it easier to iterate on. > > Anyway I just wanted to share this so that we can try to make all of this > work together at some point! > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#45>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAALCRDSZWOPPYQJRH2MV3LRI5YEHANCNFSM4LR5PSBA> > . >

[jtpio]

Thanks @bollwyvl for the input!

I've found it challenging to keep the API up properly

You mean the Lab API and the changes with new major releases?

The iframe approach is a great jump start... But eventually i think this
kind of work will need a way to move into a worker. Even loading Pyodide,
which is still the brass ring jyve is striving for, can definitely be
taxing.

Having support for Pyodide would be the killer feature 👍 (and I see that #27 is getting there progressively).

It should be relatively straightforward to have a generic worker kernel for JavaScript. With of course the caveat of not being able to access the DOM (unless some proxy / virtual dom is used maybe). But it would still be interesting to have it as a plain JS kernel and as an alternative to the other JS kernels out there.

towards features that lab just already has. I think there's a lot of space
for theme-only reduction and plugin replacement to get to more pleasing
minimalism, such that other peoples' plugins just work. Maybe the best hook
for that right now is probably "presentation mode"?

This is something that has come up quite often indeed. Many folks like the simpler look and features of the classic notebook, and it sounds like there could be good reasons for having more minimal frontends. Presentation mode is a good compromise but it still leaves a bit of chrome on the screen.

[bollwyvl]

You mean the Lab API and the changes with new major releases?

Right: the kernel/session stuff seems to be particularly volatile, and does change on point releases in ways that break jyve, because of the weird monkeypatches. I took a serious swing at 1, and gave up (not a lot of extra time for it). Will be taking a look at lab 2. I've lobbied in the past for additional API extension points to make things more composable, it's a matter of a) having time, b) getting jyve stuff working with something like master, c) doing the pr and d) waiting for a release so people can actually use the stuff.

bit of chrome on the screen.

Right: here's (one of) the kernel-side examples we've used to cut down the noise:

https://gist.github.com/tonyfast/e2e574e6fa3dcc4a4557f486d8bf0d70

It's mostly hygeinic, only firing when presentation mode is hot. It would not be a big deal to package this into an extension, plus a little more fancy stuff, but the key thing is when you're presenting/working, you can focus on the goods. But you're still paying for 5mb on the wire.

From a size-on-wire perspective: the p5notebook bundle.js is 1/5 the size of core lab, which is certainly good, but it still blocks that screen until blueprint, codemirror, react, etc. are loaded. The truly minimal thing (that would still work with lab app extensions) is probably something like:

• @jupyterlab/services 100k
• @lumino/application 50k
• codemirror 50k

and have everything be built from there, with a lot more laziness... but building up an app is not everyone's cup of tea.

[jtpio]

Closing since there is now a reboot happening in https://github.com/jtpio/jupyterlite.

And the p5-notebook use case will be just a custom JupyterLite distribution with p5 branding and p5 related kernels.

[bollwyvl]

Yup, is cool. Would also see offering the "slow reveal" iframe approach vs build-and-then-do-nonjs-magic, but that's another issue. Once lite supports federated extension, certainly consider making the p5 kernel one! While it will be nice to have a distribution just for p5, being able to combine multiple things is fun! Indeed, there's the opportunity to show interesting interactions _between_ client kernels in a way that isn't straightforward with zmq kernels.