It allows you to debug any language that compiles to JavaScript, with the caveat that the language's compiler must output source-map compatible code (or the source must be run through some other program that somehow does it).
It's a pretty simple but extremely useful idea. To use your example, the CoffeeScript compiler knows exactly which bits of generated JavaScript correspond to exactly what bits of CoffeeScript code, so the compiler can output a mapping that says "these lines of JavaScript are the result of this line of CoffeeScript...so when you step through this CoffeeScript line, execute these X lines of JavaScript, if an error occurs in these X lines of JavaScript show there error as occurring on line Y of the CoffeeScript code.
I haven't done much front-end lately so I'm not sure what if any the CoffeeScript compiler has in terms of generating source maps, but if browsers are supporting it I imagine it won't be long if it's not here already.
AFAIK, the CoffeeScript guys are working intensely on it. To some extent, any language which has accurate source position information in its parser/AST, and uses Closure Compiler on the backend can get source map output almost for free.
Yea I would imagine they are. I haven't been following the development like I used to, so thanks.
How accurate does the source position information have to be? I don't think the CoffeeScript lexer can output column numbers (at least it didn't last time I checked) and the re-writing stage might give them a little trouble. Should be doable though.
Guess I should head over to github and see how they're doing and start reading the SourceMap spec.
However, you can embed extra metadata for your specific source language if you wish, via the extension mechanism. Debug tools can then read the metadata in to do extra neat kinds of mapping (such as collapsing "native" stack frames).
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.
BTW, thanks for all the positive feedback. If you are working on a language translator to JS and end up including sourcemap support, just ping me on G+ and I'll put it into a directory of source-map enabled tools.
Link to documentation? If I wanted to build my own little JavaScript preprocessor and make it use SourceMaps in Chrome, how would I know the file format(s)?
