
Source Maps Are an Insufficient Debugging Format for the Web - mnemonik
http://fitzgeraldnick.com/weblog/62/
======
skybrian
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...](https://docs.google.com/document/d/1FTascZXT9cxfetuPRT2eXPQKXui4nWFivUnS_335T3U/edit#heading=h.xuvxhsd2bp05)

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

~~~
jahewson
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.

~~~
skybrian
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.

~~~
jahewson
Scopes are tree-shaped, what more flexibility do you need? Do you have a
reason to believe that DWARF, which has stood the test of time, is somehow
lacking in this regard? Don't forget that unnecessary flexibility is really
just needless complexity. As the article says, the final mapping from a
debugger entry to a value can be performed using JavaScript in order to have
flexibility where it is actually needed.

Any API which inspects the stack is (obviously) going to have to run in a
separate thread/stack which then means you won't be able to use plain
JavaScript to retrieve in-scope object values, as in the article. Instead
you'll have to introduce an API which provides a means to reflect over the
other thread/stack's scope tree - so the "less flexible" scope tree will
simply be baked in to your (by this point very complex) API.

~~~
skybrian
I'm not that familiar with DWARF, but its support for languages that aren't C
seems to be limited. Go apparently emits DWARF information [1] but it's
regarded as a language that doesn't have good debugger support - for example,
see [2]. Apparently Haskell (ghc) has some support but it's pretty limited?
[3]

It's not used at all for Hotspot, V8, or Dart. The way these languages work is
that they have a debugger protocol that allows the debugger to connect to the
runtime system. That isn't so far from providing a debugging library written
in JavaScript.

So I think if DWARF can work, it needs to be proven.

[1] [http://blog.golang.org/debugging-go-code-status-
report](http://blog.golang.org/debugging-go-code-status-report) [2]
[http://www.reddit.com/r/golang/comments/2h57hf/trouble_debug...](http://www.reddit.com/r/golang/comments/2h57hf/trouble_debugging_go_program_with_gdb/)
[3]
[https://ghc.haskell.org/trac/ghc/wiki/DWARF](https://ghc.haskell.org/trac/ghc/wiki/DWARF)

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

------
malkia
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).

------
malkia
"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
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.

