Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Scratch.js – Interactive JavaScript Scratchpad

hole.dev

Post reply on HN
Print view View original

21–30 of 69 posts

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

#21

Post by jraph »

protoduction wrote: post #20
angleofrepose wrote: post #14

Earlier quoted context omitted.

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 bro…

That's clever. Do you know if there is something possible using web workers? maybe running the "sandboxed code" in the worker? I don't really know how they work and if it is possible to interrupt them from the main thread.

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

#22

Post by mattigames »

angleofrepose wrote: post #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?

You could modify the AST tree using something like jscodeshift to add a function that is called in every loop (and maybe every function) and there you can "break" the loop in a pretty clean way.

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

#24

Post by protoduction »

jraph wrote: post #21
protoduction wrote: post #20

Earlier quoted context omitted.

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 bro…

That's clever. Do you know if there is something possible using web workers? maybe running the "sandboxed code" in the worker? I don't really know how they work and if it is possible to interrupt them from the main thread.

I think so, but a worker won't have access to the DOM and a bunch of other APIs, so the code would be fairly limited in what it can do. Which may be fine for some usecases!

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

#25

Post by protoduction »

mattigames wrote: post #22
angleofrepose wrote: post #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?

You could modify the AST tree using something like jscodeshift to add a function that is called in every loop (and maybe every function) and there you can "break" the loop in a pretty clean way.

A determined user will still be able to figure out something that blocks forever, for instance run a WASM program that has an infinite loop in it.

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

#26

Post by chkas »

angleofrepose wrote: post #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?

I have made something similar (https://easylang.online/ide/). It is a language of its own, which is compiled and interpreted by WASM. The problem with hanging in endless loops is solved by running the interpreter in a "web worker" that can be killed and restarted at any time.

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

#27

Post by angleofrepose »

jraph wrote: post #18
angleofrepose wrote: post #14

Earlier quoted context omitted.

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.

Yes, as the other comments get at the "hack" I'm referring to is a loop transform that adds a timer check to the condition.

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

#28

Post by angleofrepose »

protoduction wrote: post #20
angleofrepose wrote: post #14

Earlier quoted context omitted.

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 bro…

Hi, yes! I like your project. I chatted about similar things on your launch post here. You also address this explicitly on your product which I appreciate.

What I'm getting at is that these browser notebooks try to get at the desire and feeling for rapid exploration and iteration. Losing context by having a crashing logic error is a massive blow to that ideal.

I'm not saying that your or anyone elses product is only for "rapid prototyping" but it's still true that larger projects could be bit by the same errors. When I crash my native code I C-c and I'm back in an instant. When I crash browser notebook code I lose a bit of time and unsaved code. I crash browsers often in creative coding where I write many loops and don't always do them right.

It may also be that my chrome and firefox experience on linus is worse than standard, I don't know. But I have crashed my entire browser in chrome when using observable, and I thought that wasn't supposed to be possible.

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

#29

Post by colejohnson66 »

kahole wrote: post #7
robbiejs wrote: 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.

Not to be rude (I actually like it), but why build your own instead of using one of the many JavaScript REPLs already available?

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

#30

Post by 1-more »

angleofrepose wrote: post #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?

We started with a blacklist to match against while(1), while(true), for(;;), etc, but we eventually found an eslint plugin (goedel.js) that nicely tells you if the code contains an infinite loop or recursion.
Post reply on HN