Thanks for creating StarBoard - it was, as is, needed!
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 .
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).
Upon closer inspection the title should probably read “Run some Jupyter notebooks in the browser” as your website confirms the many limitations.
I chose observablehq but this is a product that also fits my needs basically perfectly.
things I'd like to know:
* how do i know this project won't shut down in a few weeks and I have to transfer out
* i want private notebooks obviously
* features roadmap?
* Private notebooks make a lot of sense, and perhaps this is where it can be a viable product as well instead of just a useful open source tool? I have plenty of runway, but still it would be more sustainable if it could eventuallu pay my rent.. Similar to the (old) github model I mean (pay for team features / private notebooks you can share with some) with some reasonable limits?
My main goal right now is to raise awareness for it. I think many many web developers especially would find the notebook paradigm really useful, but how do I show that?
* A lot of stuff.. auto save, I store every revision but currently you only can retrieve the latest, social features (e.g. recent notebooks, avatars), actual documentation (in notebooks of course).
If you have ideas or thoughts on where I should take this, do reach out! Email in my profile.
For sandboxing user content they need to be on their own origin, otherwise by opening the wrong notebook your account could be taken over.
Ideally you also have a unique origin per user as well, as otherwise they would share LocalStorage and cookies. So here every user gets <username>.notebook.host for their notebooks (in the future I might completely randomly generate it instead). This is also the domain used for static embedding.
starboard.gg is used as the main entrypoint: it is just a static website (SPA-like). And the APIs are hosted on starboardapi.com. Those two could technically be combined.
And finally there's another one.. starboardproxy.com which acts as a CORS proxy for use in notebooks.
How about Neptune legal pads?
This project is called Jew Piss Star.
Sorry, but you can't unhear it.
So Jupystar is pronounced like Jupistar.
Jupis, like lupis.
People try to be too clever with these portmanteaus, and end up with either something unfortunate or unpronouncable.
That's what I said. But differs to what you said before. /Jupi/ has only one stress; your previously mentioned pronunciation requires two, also two s rather one that exists in the word.
I'm sorry, but I can barely hear it in the first place. The lexical stress in Jupystar is entirely different to what you're claiming.
Jupystar must therefore be pronounced like Jupistar.