Hacker News Reader

Comment by phleet | Hacker News Reader

This suffers from one of the same problems as most live editors: try typing `while(true) {}` in the javascript editor - the UI thread will block and freeze up the whole page. Worst of all, you'll lose unsaved work (unless you're persisting to local storage on every character).

This problem is partially solved in the Khan Academy CS editor using a web worker - the code is evaluated in a web worker with most of the side effects stuff mocked out (which is going to be difficult for general javascript) and timed - if it takes more than a couple ms, we kill the execution and give an error. (Try `while (true) {}` in http://www.khanacademy.org/cs/new)

View on HN

It's been mentioned, but the Khan editor gets around the problem because its a close environment - and I can't run the code the user submits in to a worker easily.

The while problem has been raised before, and there is a tiny bit of protection (we parse the code line you're on, and if its a while loop, it's supposed to ignore live execution - though clearly that's not enough). It's true to say I'm still looking for a solution :)

That all said, you dont lose your work if you hit this kind of loop and it hangs the UI. The reason is two fold: 1) jsbin, since it was released in 2008 always saves code to localStorage, but more importantly, 2) it's saving your code to the server AS YOU TYPE - so you hit refresh, and you get you bin back (and the correct URL and saved in your history if you're signed in, etc).

Funny enough, I went and put in `while (true) {}` and the right hand side did show an error about it running too long. But I clicked Save and was prompted to create an account (or "...I don't want to be awesome...") and I couldn't click the buttons. I open Activity Monitor and sure enough Chrome's Renderer is pegged at 100%. I killed the process but now whenever I open the /cs/new page (even in incognito amazingly) it pegs at 100%. I also had to kill the script in Firefox but when I refresh the pages it's okay. I guess while(true){} is always nasty.

I'll reply about the while stuff separately, but jsbin shouldn't and doesn't prompt anyone to create an account. The only two features you don't have access to is the history, and the /[user]/last shortcut.

Everything else, including saving, is available as a non registered and anonymous user.

I don't think the webworker solution would work for something like this, anything that needed to use anything outside of the workers context would break. It seems like khan's environment is much more restricted, so they can get away with it.

Yep - totally right. It would involve mocking out the entire browser API in a way that would somehow still follow the same codepaths. That said, it could still catch some things. If the web worker errors out, you just completely ignore the errors and just run it anyway. But if it times out, it's (almost) definitely going to time out in the real page too, unless you're waiting for some specific DOM event or something weird.

Any detailed explanation available about how this is implemented (other than by having to dig in the code...)?

Didn't looked into it but I guess you just need to pass the code as a string to the WW and then use new Function to generate/run the code inside it.

There's a significant amount of voodoo involved (mostly crazy with() {} statements) in the CS editor that only John Resig fully understands AFAIK, but the rough idea used was to ship the code over to a web worker where all the global APIs it might use were mocked out. This was a relatively short list for KA CS since it's boxed into the processing framework with a few extensions, but would be pretty complicated for full browser environment (probably bordering on impossible). Then we start a timer in the main UI thread, and if the web worker doesn't respond in some amount of time, we kill the web worker and present the error message.

Reply on news.ycombinator.com