I tweeted about this just now (https://twitter.com/BlurSpline/status/642871426920255489
) but with limited characters I wonder if people realize how cool this actually is! http://brrian.org/glsl-simulator/
yeah, the idea isn't entirely new - there's a MESA GLSL emulator and Chrome has a build in software renderer for GLSL... but since most webgl stuff is written in JS, and ability to emulate GLSL in JS I think it's a beauty itself.
one of the things this is solving is helping debugging writing shader code. GLSL code gets sent to the graphics unit, and it's sometimes not easy to trace and debug stuff in there. sometimes I write values into a texture, render the texture to screen, and read back the pixels and convert them in values just to check out if numbers are what I was expecting. being able to step thru glsl code (thru it's interpreted js code) like a debugger is awesome. Just checkout this example! http://brrian.org/glsl-simulator/demo/debugger.html
you could run esprima/Istanbul to run code coverage on the generated code (yeah it's kind of lame analyze code at that stage instead of at the glsl ASTs, but its still an idea). you could also easily write tests that expect the exact pixels that would be rendered for your webgl code. most often these days, you could run a headless browser for tests but you needed a way to interface or emulate the gpu one way or another to get results from webgl. i guess glsl-simulator would be another way to grab screenshots from webgl code (whether for archival or comparison for regression tests let's say for three.js)
another way to look at glsl-simulator: it's a software webgl renderer. there's of course a SoftwareRenderer in three.js but assuming you have you a library or piece of code that targets only WebGL, now you have an option of plugging that in to be running software/js only.
another random idea though somewhat similar to some I had in the past: since GLSL code is mean't to be executed in parallel, one could make glsl-simulator run parallel. like, spin off Web Workers to render a huge canvas. It'd could easily run in node too, spin off a couple of child node processes to help render a piece of glsl code. Or a wilder idea, create the biggest massively largest webgl render ever. Imaginary 1Mx1M pixel render of a fractal for example. Could get people running workers in their browser, help render chunks of that, sent it back to a server. Esp. with those kind of code in shadertoy, it probably scale well.
other points: mattdesl also mentioned this could be a way to validate glsl code. +Ricardo Cabello
also hints +Jaume Sánchez
on a browser extension that does this. Perhaps some guys (like Brain himself) might want debuggin in WebKit too but it'd be cool to see any of these more out in the wild too.
and strangely, i should be asleep at this time. my body is somewhat messed up. like jetlagged without actually travelling. better sleep otherwise i can't work later /ends gibberish