And if your problem is with JavaScript as a language, you can already use a myriad of languages that reliably compile to it. Do you come from a Java background? You’ll probably like Dart, from Google. More of a functional kind of developer? Try ClojureScript, which is an impressive, well-maintained and well-performing implementation of Clojure on top of JavaScript. Coming from Ruby? You’ll be almost at home with CoffeeScript. You get the picture.
God no. Instead of having to use a single awful language all the time I get to choose what language to transpile to javascript and I never have to look at or think about javascript at all. Unless of course there are bugs and then you get to experience the pleasure of debugging machine generated javascript. Maybe some people are filled with joy by the thought of debugging generated js, all I can say is that those people are certifiably insane.
How about we work on platforms that support more that one language as first class citizens. Is that really such a crazy idea in 2013?
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.
Even without source maps it is not such a big deal as people who have no experience using cross-compilation would think. I write a very big game engine with GWT (http://www.webworks.dk/enginetest) and have no problems debugging. Clients send neat stack traces back to the server and I can even obfuscate the application code and using symbol maps deobfuscate the stack traces on the server.
True. I think it's also important to recognize the points against including many languages on a phone, though. A lot of the power of mobile applications derives from their integration with a standardized event system integrated in to the phone. Maintaining such a beast at low latencies and in a well-tested state across multiple languages is not exactly desirable overhead. Then there's the space concern, relative difficulties providing cross-language-platform sandboxing/security, etc...
"How about we work on platforms that support more that one language as first class citizens. Is that really such a crazy idea in 2013?"
That was the nice things about the BBC Micro computer, you could code in Assembly and BASIC right out of the box. Since then the trend has been towards ever higher layers of abstraction. Even in python you sometimes still get indecipherable OS level error messages, but most of the time the tools work well.
It would be nice to have other languages in the browser, but at this point it seems as likely as python built into the processor. At least something compiled to JavaScript is unlikely to be any less secure than JavaScript on its own.
One of my 'things to do: not urgent', includes porting all the examples from 'Practical Programs for the Acorn Atom and BBC Micro' to JavaScript.
I checked, and yes, there is an accessible developer console even in Chrome on my Chromebook, so it seems fitting that programs designed to teach the basics of programming to one generation, should be brought up to date to be used to teach another generation.
Ok so is the solution a standard bytecode for browsers ? Or is is NaCl ? Or PNaCl ? Or something like Hypercard ? Or do we tear down the monoliths that browsers are in small Unix-style components ?
"uzbl-core: main component meant for integration with other tools and scripts
- Uses WebkitGtk+ for rendering, network interaction (libsoup). Css, javascript,
plugin support etc come for free
- Provides interfaces to get data in (commands/configuration) and out (events):
stdin/stdout/fifo/unix sockets
- You see a webkit view and (optionally) a statusbar which gets populated
externally
- No built-in means for url changing, loading/saving of bookmarks, saving
history, keybinds, downloads..."*
Compare Javascript and Java Bytecode. The respective virtual machines are IonMonkey,V8,etc vs Hotspot,Harmony,etc. All those VMs are pretty portable across various architectures and operating systems. The syntax is C-like vs binary stack machine code. Both languages come with a documented standard, reference implementations, and standard libraries.
Sure, Javascript is somewhat harder to parse than Java Bytecode. Java Bytecode usually runs faster. However, from a high-level software architecture perspective there is not much of a difference. And the parser is usually not the performance critical part in any VM.
I never said it doesn't run in a VM. JavaScript is not bytecode. When the code is run, I grant you that you that the JIT will compile to some sort of bytecode. But you can't take that bytecode and run it under any virtual machine.
As for bytecode "running faster", that's entirely up to the JVM implementation. Given a feature complete JavaScript bytecode, I don't see why a JVM needs to be faster than the JavaScript VM.
You may be conflating the JIT nature of JavaScript vs fully compiled Java apps. With JavaScript, it interprets (even compiles) as it gets the JavaScript code, whereas Java code is already compiled into bytecode.
The V8 engine [0] compiles Javascript to assembly. Maybe it uses some other intermediate representation internally, maybe not. Why would you want to use bytecode for some random VM as internal representation?
You can run Javascript anywhere [1], why would you want to compile it to some portable bytecode?
The situation is better in Dart than in languages that only compile to JS, because during development you're usually using the VM and don't have do deal with the translation. If you have an error, you have a full debugger and nice stack traces to diagnose it.
If there's an error in the dart2js output that doesn't occur in the VM, then it might be a bug in the dart2js compiler. That would be unfortunate, but the goal - backed by a very large test suite - is for that not to happen. If it does, then source maps can help.
God no. Instead of having to use a single awful language all the time I get to choose what language to transpile to javascript and I never have to look at or think about javascript at all. Unless of course there are bugs and then you get to experience the pleasure of debugging machine generated javascript. Maybe some people are filled with joy by the thought of debugging generated js, all I can say is that those people are certifiably insane.
How about we work on platforms that support more that one language as first class citizens. Is that really such a crazy idea in 2013?