Live data from Hacker News

Show HN: Scratch.js – Interactive JavaScript Scratchpad

hole.dev

11–20 of 69 posts

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#11
post #7
post #2

Cool stuff! What was the reason for you to make this?

I find myself opening and using the web console to do simple tasks like string manipulation, maths, sorting often. I wanted a dedicated and persistent way to do this. And also just a place to keep notes, urls and stuff. So I made this "literate programming" notepad. I'm also former Emacs user, and I like the lisp scratch buffer there, which is similar.

I love how simple and effective this is.

I'm also building a web-based literate programming environment called Starboard[1] that's probably a hundred times the amount of code (but then it has additional features such as top-level await, plugin, and Python support).

Consider supporting lit-html[2] literals instead of strings for HTML output, it works really well in notebook environments.

One more thing you can consider: a esm tagged literal that uses import(), you can then use ES Module imports to dynamically load code. Here's a blog post about that approach [3]

[1]: https://starboard.gg [2]: https://lit-html.polymer-project.org/ [3]: https://2ality.com/2019/10/eval-via-import.html

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#12
post #5
post #3

When you paste something it keeps the formatting, intended?

Yes, I guess. I'm pretty used to ctrl+shift+v-ing to remove any formatting. I'm now considering removing formatting by default. Know a simple way?

.innerText?

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#13
Do you, or the broader community, have any ideas about solving infinite loops? I'm on mobile so I can't test this at the moment, but I imagine that while(1) crashes the tab.

What would an MVP operating system like ctrl-C functionality look like for execution environments in the browser?

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#14

Do you, or the broader community, have any ideas about solving infinite loops? I'm on mobile so I can't test this at the moment, but I imagine that while(1) crashes the tab. What would an MVP operating system like ctrl-C functionality look like for execution environments in the browser?

I am aware of multiple hacky solutions, such as loop detection and adding timeouts. This fails in most non-trivial creative coding applications due to long running code. I'm interested what it would take to come up with a general escape hatch like any shell user has.

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#18

Do you, or the broader community, have any ideas about solving infinite loops? I'm on mobile so I can't test this at the moment, but I imagine that while(1) crashes the tab. What would an MVP operating system like ctrl-C functionality look like for execution environments in the browser?

I am aware of multiple hacky solutions, such as loop detection and adding timeouts. This fails in most non-trivial creative coding applications due to long running code. I'm interested what it would take to come up with a general escape hatch like any shell user has.

A timeout would most certainly not trigger during a busy loop in JS. Timeouts can only trigger when the main thread is not running code.

Browsers will complain against code running for too long without interruption though.

Re: Show HN: Scratch.js – Interactive JavaScript Scratchpad

#20

Do you, or the broader community, have any ideas about solving infinite loops? I'm on mobile so I can't test this at the moment, but I imagine that while(1) crashes the tab. What would an MVP operating system like ctrl-C functionality look like for execution environments in the browser?

I am aware of multiple hacky solutions, such as loop detection and adding timeouts. This fails in most non-trivial creative coding applications due to long running code. I'm interested what it would take to come up with a general escape hatch like any shell user has.

On Starboard[0] I approached this by sandboxing the notebook code in an iframe on a different origin. This sandboxing has to be done anyway to prevent XSS.

If you type while(true){} in a notebook only the iframe will break (and usually your browser will prompt you after a while to kill it). When you do only the iframe is no longer functional.

I don't think there's an elegant way to solve it any differently in the browser.

[0]: https://starboard.gg

Post reply on HN