6 ms·
Thanks for sharing, this is a cool project. I've been working on something similar on and off for a while, and I've found the space to be fascinating and somew
by angleofrepose 6y ago
Thanks for sharing, this is a cool project.
I've been working on something similar on and off for a while, and I've found the space to be fascinating and somewhat puzzling. Most of the first questions I try to ask about these in browser notebooks don't have clean answers. In no particular order:
- Do you have any ideas about solving logic errors? As it stands right now a while(true) loop crashes the page and consecutive re-openings of the page for a short while (in chrome). What about things like document.body.innerHTML = "" (you actually seem to handle this pretty gracefully, I'll see if I can poke more holes in this another time). For what it's worth none of the online notebooks I've seen have a satisfactory solution to infinite loops, loop timeouts are too blunt an instrument and crashing the tab can take the browser minutes to recover.
- Is there a particular reason you use eval rather than the new Function constructor? From what I've read using new Function is much more performant, and other than different scoping a better choice than eval. Can't find the link at the moment, but it was wrapped up in the mdn[1] design docs for their codebox examples.
- I see you're using the first codemirror 6[2] beta release, how are you liking it? I really enjoy the interface so far.
- Do you have any favorite resources or inspirations about why you went about building a hackable offline local first notebook environment? I particularly like the experiments at Ink and Switch[3]. (many related hn submissions). As well as webstrates[4].
My attempt at this game is to break out of the notebook style single column layout and embrace an art board style canvas, which is a rather radical idea in that it is not obvious what that should look like or how basic interactions like hierarchies or execution order should look, but fun to explore. I also desperately want to prevent crashing as a result of logic errors and workflow footguns(like deleting DOM elements or overwriting storage), to that end I have a separate storage of scripts to rebuild a "safe boot" interface, but there is more thinking to be done here.
I look forward to poking around your code some more soon. Thanks for posting.
[1]: https://developer.mozilla.org/en-US/ https://developer.mozilla.org/en-US/
[2]: https://codemirror.net/6/ https://codemirror.net/6/
[3]: https://www.inkandswitch.com/ https://www.inkandswitch.com/
[4]: https://www.webstrates.net/ https://www.webstrates.net/
Edited out a question about your motivations. I reread your comment and the about page and I realized my motivations are similar to yours. While observable doesn't have a few of your key points, it is a fantastic product. The reason I don't settle on it is that I'm interested in experimenting with the environment outside of a notebook-with-cells interface.
- rewq4321 6y ago> As it stands right now a while(true) loop crashes the page > [...] I also desperately want to prevent crashing as a result of logic errors I could be wrong here, but I think the new Site Isolation stuff in Chromium[0] may mean that you can sandbox an iframe to a different origin, so that the main threads of the top frame and the iframe aren't synced. So the iframe where the code is running would freeze, but the main frame would still be responsive. Again, I may have misinterpreted this because I only read about it in passing, and it was a while ago. [0] https://www.chromium.org/Home/chromium-security/site-isolation https://www.chromium.org/Home/chromium-security/site-isolati...
- angleofrepose 6y agoA brief skim through that doc looks like it is about a kind of security that's not relevant to my project. I'm trying to protect the user from themselves while simultaneously giving the user full power over the document. Web workers are interesting and relevant to this use case, however the almost total isolation doesn't lend itself to manipulating the DOM without the user explicitly writing a custom API to interpret the worker's messages. So, back to the same problem. Thanks for the link. I'll do some digging into chrome's sandbox[1]: [1]: https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md https://chromium.googlesource.com/chromium/src/+/master/docs...
- CuriousSkeptic 6y agoI’ve been thinking a little of doing something in this space. But doing so as part of a larger project involving a new programming language so perhaps not applicable to you situation. I also want to leave the notebook style, focusing more on graph approach. Think higher order spread sheet without the grid. One, somewhat tangential, thought I’ve had to handle the infinite loop issue though. Is to fragment the language somewhat like they suggest in the out the tarpit paper. Trying to avoid infinite loops by construction, only used at the highest orchestration layer to schedule execution blocks, where the runtime can keep track of things going out of control. Not sure what it would take to extract a “total” subset of javascript though. But one idea would be to insert a trampoline breaking out of infinite loops often enough for error handling.