We've had some of these problems with GWT, but I think some of them can be solved with a much simpler mechanism than serializing an AST. For example, for each

We've had some of these problems with GWT, but I think some of them can be solved with a much simpler mechanism than serializing an AST. For example, for each symbol we record, we can simply introduce something called a 'scope identifier' and then define a language specific mechanism by which debuggers can compute scope identifiers. Consider the following problem for GWT: class Foo { String hello; } class Bar { String world; } Both of these can be compiled and obfuscated an an object with field 'a'. So when encountering a heap reference to an object with field 'a', does it deobfuscate to 'hello' or deobfuscate to 'world'? We have many kinds of scopes: global scope, object scope, function scope, etc. In this case, its an object scope. If we uniquely identify each scope, we can perform the mapping as long as there's a way to compute runtime type, e.g. Store 'a' as '2:a' (scope identifier '2') Put a mapping in the sourcemap that 'Foo' maps to '2', and now we can introspect the heap reference, determine it is 'Foo', map it to '2', and properly display it as 'hello' Different languages may have different ways of setting up classes and defining runtime types. GWT for example, does not rely on JS constructors, but instead hangs a classId off of the prototype. I think Dart does something different. In any case, it is a simple extension to the existing format and backwards compatible. The only runtime API needed is a function getScopeIdForReference(obj) which takes a compiled object and gives its scope. The AST approach I think has several problems: 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. 2) it increases the download size for consumers who are not developers and don't need the maps 3) if written out as a separate file that co-exists with a stripped binary, it increases memory requirements of the debugger. The way Google deploys Gmail, for example, we use sourcemaps in production as well as development. When exceptions are thrown on the client, the stack traces are reported back to servers, deobfuscated via sourcemaps, and put into a triage system. A person looking at a bug report sees a deobfuscated trace, but the consumers aren't burned with having to download the sourcemaps in annotated js. I think the idea of defining an actual sourcemap API for the debugger (getDisplayValues, getLocals, eval, etc) has a lot of value, because these function are source-language dependent, so having GWT/Dart/Emscripten/CoffeeScript/etc generate them is useful. But I don't think annotating the actual JS, or switching the sourcemap format to an AST is a big win. Yes, it is a simplification, but it also trades off other useful properties of sourcemaps.