Very interesting. The reason we didn't want to use GWT was precisely because of the difficulty of debugging. This is a big step in the right direction.
The talk emphasizes debugging js as output of another language. But did I understand correctly that it can be used to debug js programs directly? Makes sense and would be awesome.
Yes, if you have regular hand-written JS, and let's say you run UglifyJS, YUI Minifier, or Closure Compiler, to generate compact, optimized JS, with source maps, the debugger will show the original JS source.
The demo I showed also is using SuperDevMode for GWT, which dramatically speeds up the compile. Notice, I compile a project (the Mail sample) of several hundred Java source files in less than 2 seconds.
I think what they mean is say you have a bit of obsfucated, minified, and or complex JavaScript code you want to reverse engineer. You can start writing a an "unobsfucated" version in JS, pseudocode, whatever you wanted....and use source-mapping to switch between looking/working on that and the original in the debugger all while the browser is actually executing the original code (negating worries that your translation is incomplete or behaves differently, these are concerns during certain steps of the process...obviously you want to end up with a perfect translation in the end)
That would be a useful tool in reverse engineering.
The talk emphasizes debugging js as output of another language. But did I understand correctly that it can be used to debug js programs directly? Makes sense and would be awesome.
Great job - again.