JSBin(jsbin.com)
jsbin.com
JSBin
http://jsbin.com/
10 comments
Very nice. I particularly like being able to spin off the final page on a separate URL. Great for demoing HTML5/CSS3 features. I am teaching a class on HTML5 tomorrow and will definitely mention this.
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)
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)
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).
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.
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...)?
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.
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.
I personally prefer http://JSFiddle.net
I think jsFiddle is great! However, I haven't really tried any of the others. This one looks nice, and just at first glance one thing that I find really interesting is the built in console. I think the devs at jsFiddle should totally implement something like this. Probably the biggest reason I don't use jsFiddle more often is that after I build a demo, occasionally I will need to use the Chrome console to get at and inspect one of my objects or the like, and for whatever reason I can't get at the objects in my fiddle, the console never seems to work right. I will probably give this one a whirl instead the next time I want to use jsFiddle. If everything else is on par with jsFiddle and it has a good console with visibility of all my objects then I'll probably switch to it.
Does anyone know if there is a way to get the Chrome console to work right, ie. have visibility to all the variables, functions, etc that I create in my fiddle?
Does anyone know if there is a way to get the Chrome console to work right, ie. have visibility to all the variables, functions, etc that I create in my fiddle?
In chrome you can change the context like this: http://img42.com/oNrDj
There is also CodePen ( http://codepen.io/ ), and dabblet ( http://dabblet.com/ ) now seems to have (alpha) javascript support, too; the more, the merrier :D
jsfiddle is SO much better. I respect Remy, but I just like the way jsfiddle is. I tried all of them out and I found that jsfiddle > jsbin > codepen > others. The panels are just more intuitive and it feels less constrained than the others.
yeah generally i've preferred fiddle, but this is a nice redesign. might give it a whirl the next couple of times i need it, see how it goes.
I wonder why? It doesn't update result as you type, doesn't support Less, CofeeScript etc., doesn't have console and until recently it used ancient and broken version of codemirror.
Also http://jsconsole.com which also lets you connect to remote sessions (eg on a phone).
No tab completion for tags. Bleh.
How about http://cssdeck.com/labs ?
[deleted]
Why did no one notice that Dave runs away if you get it too dizzy?
Nice for some quick and dirty testing, but if I'm going to spend more than 2m hacking something together I prefer Chrome and gvim. I can't work without the Chrome Dev Tools or vim, and jsbin just doesn't work well enough with these for my purposes.
It's good for sharing code and helping people though. :)
It's good for sharing code and helping people though. :)
great , i use http://plnkr.co/ too which allows to create one's own files.