> 1) if the annotations are present in the shipped obfuscated code, it leaks information that people don't want. Many people do not want to leak the source file

> 1) if the annotations are present in the shipped obfuscated code, it leaks information that people don't want. Many people do not want to leak the source filenames or directory structure of production apps. You would be able to continue using the approach you describe for GMail. There is no reason to publicly serve the debugging information unless you want to. > 2) it increases the download size for consumers who are not developers and don't need the maps No, the debugging information would still be an auxiliary file like it is now. 3) if written out as a separate file that co-exists with a stripped binary, it increases memory requirements of the debugger. Debuggers need to keep the source map around now, anyways; this is no different. Regarding the scope identifiers: it would solve scoping for the most part, but it fails to handle the last three requirements I defined: - It should provide a way for the JavaScript debugger to display values in a meaningful way. - It should optionally provide an eval capability, for use from a REPL, watch expression, or conditional breakpoint. - The format should be future-extensible. That is, when SourceMap.next v2 rolls out, any SourceMap.next v1 consumer should still be able to parse and use instances of SourceMap.next v2 (although without the new features, of course). Inspecting values would still be a pain, and you wouldn't have watch expressions or conditional breakpoints, etc. Also, much of the value in what I described in the blog post is the future-extensible format. It allows us to fix our mistakes post facto.