Source Maps Are an Insufficient Debugging Format for the Web

by mnemonik • 11 years ago

71 13 11 years ago

Touche• 11 years ago

fyi, the author of this post is the lead developer of mozilla/source-map, the defacto SourceMap library.

skybrian4• 11 years ago

We do need a good way to inspect the JavaScript heap when it contains data structures from non-JavaScript languages. However, I'm not convinced this should be represented as data. It seems better to represent it as a reflection API that's implemented as a JavaScript library provided by the compiler. The debugger can load the javascript file into the web page when needed, and it can use whatever data format it likes.

Chrome is working on a way to this [1]. However, it's not done yet, and it needs to be be turned into a real standard. It's also not likely to work well for asm/wasm as-is.

New standards are important but we also need to properly implement the standards we already have. Sourcemaps have been around for years but they're not fully implemented by most browsers that claim to support it. (Firefox sourcemaps didn't work well when I tried it in January, though some bugs have been fixed since then.) I think someone needs to write something like the Acid tests [2] for browser debuggers.

[1] https://docs.google.com/document/d/1FTascZXT9cxfetuPRT2eXPQK...

[2] http://www.acidtests.org/

mnemonik• 11 years ago

Note that the proposal you linked is solving a different (albeit related) problem compared to what I discuss in the article.

That proposal is about formatting the JS-implementation of Java/Clojure/etc specific objects/types at the source-level.

The article is discussing how to even locate a binding's value. The more aggressive your compiler, and the further your source language from JS, the more this becomes a problem that needs solving. However, this is also a problem for people that simply need to debug minified JS and don't want to figure out which source-level variable "aB" refers to, or struggle to figure out that some other source-level constant variable was inlined and can't be inspected by the debugger anymore.

Neither of the two solutions need to block progress on the other. Neither of the two wholly fixes the other's problem, either.

jahewson2• 11 years ago

Reflecting over JavaScript objects isn't going to allow you to reconstruct the original source structures from a non-trivial transpilation. Any case where there isn't a 1:1 mapping won't work.

The Chrome feature you link to deals with custom formatting of JavaScript objects, which is not the same thing. For example, what happens when two JS objects map to one object in the source language? The browser requires knowledge of the source language to handle that. Also dumping objects is very different from inspecting the scope tree - the latter requires knowledge of the current stack frame, closures, etc. which are only available to the debugger.

skybrian4• 11 years ago

I agree that inspecting the stack is different than inspecting the heap; the Chrome proposal doesn't cover that. But we could come up with a similar API allowing the debugger to pass in a representation of the JavaScript stack to a stack deobfuscator and get back a language-specific representation of the stack for display; it's basically the same thing. (A complication: when a program is written in multiple languages that call each other, we need to figure out which language each portion of the stack belongs to.) Stack frames are often not one-to-one either due to inlining and variable reuse, but for a given stack frame and a given location in the source code, there will be some interpretation of the JavaScript stack frame that makes sense.

The idea is that the reflection library has all the language-specific knowledge baked in, because a compiler generates a different .js file containing debugging information for each program, just as it generates a source map today.

More generally, any information sent as a data file can just as easily be sent as a JavaScript file if we can come up with a suitable API. A data format will in general be less flexible than one that includes the possibility of running code.

abecedarius• 11 years ago

This idea of a procedural interface between compiler and debugger goes back Norman Ramsey's ldb: https://www.cs.tufts.edu/~nr/retargeting-summary.html (if not further). It seems like a good one.

malkia2• 11 years ago

"We can embed snippets of JavaScript within the debugging data to locate a binding's value." - I see this as a security risk, but then again so much code is executed by the browser so it probably is okay.

db48x• 11 years ago

It would be executing in the same tab as the javascript that the user is debugging, so it's no different than the javascript on the page in the first place.

malkia2• 11 years ago

I'm fairly new to the web-development, and on my new job I've been tasked to use java (new to me) with gwt (just knew the name) which is translated to javascript (yes, not enough experience there).

Now SourceMaps and Chrome/Firefox debugging tools are great savers. I wish Eclipse had better debugging (actually it seems it has, since it's also new to me, the curve for learning it is much steeper - I'm an ex - Visual Studio Debugger guy :)).

But even with SourceMaps gwt translated (from java->javascript) names do not always match - often _g or _0 _$ are added, and object properties are intermixed with original java defined ones, and some internal - I'm used to it now, but was wondering whether it would've been better if it work ideally (e.g. show real Java "view" of the things even from the "Javascript" land). While this might've been the right choice, what I have now gives me more usable information.

What doesn't work always, is that sometimes the debugger would display the javascript, not java code (maybe gwt's fault, or something I do incorrectly with gwt's SuperDevMode )

I wish there is an option (for gwt, and other languages) to somehow show the transition, and allows intermixing when displaying. To give you an example - When debugging "C/C++" code most of the debuggers can intermix the assembly generated code in there... I'm not sure whether this would be as good as intermixing java and javascript (or say another language with javascript) because they look very similar, but at least to allow me to sometimes see the javascript, rather than always show me the java code (it's possible that this is already available, and I haven't found it yet).

Source Maps Are an Insufficient Debugging Format for the Web

Related Stories