How does this differ from debugging any other VM? Except in Javascript you're almost guaranteed your 'crash' will come as an exception with a stack trace – guaranteeably raised by the only executing single thread that could contribute state to the crash.
Debugging a Java or a C crash is infinitely worse, since instead of comparatively pretty symbols and a verifiably correct trace, you have a vector of bytes where your stack is supposed to be, and any number of threads running third party libs that could have written all over your frame pointers, and instead of semi-structured code you have a few thousand flattened basic blocks, devoid of any type information, absolutely swamped in gotos and boilerplate prologues/epilogues.
I'd much rather debug a JS exception than the subtle mental math required to statically analyse the stack operations of some assembly.
>Debugging a Java or a C crash in infinitely worse, since instead of comparatively pretty symbols and a verifiably correct stack trace, you have a vector of bytes where your stack is supposed to be, and any number of threads running third party libs that could have written all over your frame pointers
My experience of crashes in C is that the OS typically provides a decent backtrace including function names, not just a 'vector of bytes'. Your millage may vary, I expect it depends what kind of C you are writing on what platform, if you strip symbols etc. Sure your memory could get totally trashed beyond recognition but that has not been very common in my experience. I'd like to point out that I was not advocating writing C. I've not used Java but I always assumed it gave you decent stack traces.
>instead of semi-structured code you have a few thousand flattened basic blocks, devoid of any type information, absolutely swamped in gotos and boilerplate prologues/epilogues.
I've honestly no idea what you are talking about here. Java code swamped in gotos?
>I for one would much rather debug an exception in JS than the mental math required in statically analysing the stack operations done by a chunk of assembly.
If I'm writing Python I want a Python exception. If I'm writing Ruby I want a Ruby exception. Not an exception from JS code that I did not write. I have no idea what 'mental math' has got to do with this.
On many architectures almost any stack overrun will overwrite the frame pointer in C, resulting in a corrupted stack trace.
As mentioned in my second comment, I slightly conflated what C and JVM crashes look like – the comparison was poor.
> I've honestly no idea what you are talking about here. Java code swamped in gotos?
Yes, the JVM has goto and your favourite compiler probably emits it, it's just not exposed in Java. If we're to compare the similarity of debugging a crash on the JVM to one on the "JSVM", then we cannot discount the complexity of the toolchain producing the target JVM code. If we assume that toolchain is bug free, then we must also assume a similar compiler targeting the JSVM is bug-free. At which point the OP should not discuss trying to debug Javascript – in this scenario it should never be required.
If instead we assume the JVM compiler and the JSVM compiler are not bug-free, then we must account for the debuggability of their languages. In the JVM one works in terms of stack offsets and goto (see http://en.wikipedia.org/wiki/Java_bytecode_instruction_listi... ) while useful constructs like "string key -> Object map" are totally missing (aka. a Javascript object), and all complex expressions are lowered to a long series of basic instructions, all involving stack manipulation.
In contrast a JSVM-targeting compiler can emit human-readable expressions and control structures, has no access to goto or stack manipulation instructions, and short-term architectural choices about how those constructs are further lowered is not baked into the language. Each individual implementation can choose their own approach, and improve on it in the future without requiring recompilation.
The result is that given a bad toolchain (and currently the JS transpilers really are all quite bad, and JS lacks some trivial features like source maps), the JSVM is an inherently more human-friendly debug target with less assumptions about the runtime environment. By now it should be clear that to compare you must discount the short term comparitive maturity of existing JVM compilers – an excellent idea when making long term architecture decisions. Additionally since in JS there are no threads contributing to shared state, code flow is also easier to understand.
[Edit] If we're to discuss anything like supplanting Javascript as the language for the web in the long term, let's not resort to 1980s architectural notions about static, totally inaccessible binary formats. Approaches like PyPy are far more interesting – given a minimally modified existing language, annotate it such that an implementation can build an optimizing interpreter for any language implemented in that existing language. Imagine Javascript being that existing language, and suddenly all the upheaval and backwards compatibility destruction disappears. Your JS-authored language interpreter could still function in old browsers, it'd just execute more slowly.
Maybe eventually we will have 'sufficiently smart transpilers' and interactive debuggers for languages that target javascript and don't expose the 'JSVM' but that is not the case at the moment. Mozilla said "And if your problem is with JavaScript as a language, you can already use a myriad of languages that reliably compile to it", i.e. if you don't like javascript you don't need to use javascript. This is what I was responding to, because I don't see it being true in the near future (next several years at least).
Right now source mapping is only working between uncompressed/combined JavaScript to compressed/uncombined JavaScript
Which was exactly my point. The tools for targeting javascript from other languages are non-existent at the moment, never mind mature enough that I would want to rely on them in production.
As an aside, am I the only person who reads things like this and is filled with a sense of foreboding:
The spec mentions cross site script inclusion issues that could arise from the consumption of a source map. To mitigate this it's recommended that you prepend the first line of your source map with ")]}" to deliberately invalidate JavaScript so a syntax error will be thrown.
> How does this differ from debugging any other VM?
You can run a plethora of languages on the JVM and get full debugging support - i.e. an application crash will show you where in your code things exploded, rather than showing you a trace into generated code (or more applicably in the case of the JVM, bytecode).
> Debugging a Java or a C crash is infinitely worse, since instead of comparatively pretty symbols and a verifiably correct trace, you have a vector of bytes where your stack is supposed to be, and any number of threads running third party libs that could have written all over your frame pointers, and instead of semi-structured code you have a few thousand flattened basic blocks, devoid of any type information, absolutely swamped in gotos and boilerplate prologues/epilogues.
I don't have a huge amount of experience of debugging in C, so I cannot comment on how accurate your statement is for C, but for Java it is absolutely not true. That scenario bears no resemblance at all to debugging Java applications.
To be pedantic - you can't put Java and C crashes together unless you mean JVM crash. If I dare say - Java stack trace information is much better than JS stack traces.
Sorry, I'm conflating my own crash experiences. :) You're totally right, a JVM and a JSVM can crash in horrendous ways, but 99% of the time you'll get a nice stack trace.
Debugging a Java or a C crash is infinitely worse, since instead of comparatively pretty symbols and a verifiably correct trace, you have a vector of bytes where your stack is supposed to be, and any number of threads running third party libs that could have written all over your frame pointers, and instead of semi-structured code you have a few thousand flattened basic blocks, devoid of any type information, absolutely swamped in gotos and boilerplate prologues/epilogues.
I'd much rather debug a JS exception than the subtle mental math required to statically analyse the stack operations of some assembly.