TraceGL consists of two parts: a node.js-based server and a WebGL-based client that runs in the browser. The four-pane browser UI shows a mini-map of the trace at the top left, a zoomed-in part of the trace top right, a stack-trace bottom left and the code itself bottom-right. When hovering over variables in the code, the UI shows the value that the variable had at the time. In addition, code execution paths for control flow are visualized.
To find out more about this project, InfoQ talked to its creator, Rik Arends.
Why do we need TraceGL, aren't the browser-integrated debuggers good enough?
Browser debuggers have definitely been getting better, but they operate in 'breakpoint/step' mode. First, you have to know where to put the breakpoints, and if you step over the wrong function you have to start all over again. With a trace, all execution is recorded. This means that instead of stepping, you see all logic at once, all variables and function arguments are visible, and you can use search, and data aggregation visualisations. You don't miss anything anymore. Also as it is a recording, you don't interrupt the program. Especially with event based code, behaviour is different if you put a breakpoint somewhere, with tracing code behaves more natural. And now the recording can be shared, which enables new ways of aiding debugging in a quality assurance process.
TraceGL has definitely taught me a lot about my own code and libraries like jQuery just by wandering around the code.
Are there any types of applications that this is especially useful for?
The more code you have, the nicer having a tracer is, especially if it's not all your own code. Use it on any reasonably complex HTML5 app and you will learn many new things about your code. Seeing what your code does as you move around the UI is quite lovely. However I have to say that TraceGL is also very useful for Node.js. As it is entirely event driven, breakpoint debugging is not a natural fit, but tracing is. The availability of a closure stack allows you to jump in and out of callbacks by simply clicking on the function, which is very handy. It's like getting a window into your server and being able to see what is going on.
What is the technology used to implement the traceGL UI?
TraceGL can instrument and display the output of a CoffeeScript compiler, but I don't have support yet for source-maps to neatly map it back to the original CoffeeScript source.
While TraceGL is not an editor or IDE, it does give a similar "live programming" feel as LightTable. Whereas LightTable does this by showing results of individual Clojure functions and allows editing to affect the results, with TraceGL you keep using your own editor, and use the TraceGL UI to visualize the codeflow either live, or after the fact.