Source Map Standard
I don't know if it makes sense to become part of the language standard considering that seems like its much more related to environment/tooling than the language itself. However, I would also like to take the opportunity to say thank you, because I am really excited about source maps!
I am not part of TC39. I do not really have any opinion on whether it's a good or bad idea, but I have some questions (below):
Le 11/04/2012 20:11, Joey Schorr a écrit :
Greetings ES Discuss!
We (Joey Schorr and John Lenz, CCed) are some of the authors of the source map specification that is now implemented by WebKit and Firefox, as well as a number of compilers (Closure Compiler, GWT and soon CoffeeScript). Given that the specification is becoming a de-facto standard for mapping of code which is compiled to JS, we were curious if there was any interest in making it an actual standard under TC39.
What's your interest in seeing this happening? What would be the benefit for you? For the spec?
The current specification can be found here: docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit, with a number of contributions from all the various parties involved.
It seems like a good specification already (I can't see a copyright or licence. What's the status on that?). And you have two interoperable implementations apparently. What more would you need from a standardisation process? Reaching out more browsers to adopt it?
As much as I enjoy JavaScript, I'm aware of its limitations and I'm looking forward to more languages compiling down to JavaScript and your work is an excellent step towards having more of such languages, so thank you :-)
On Wed, Apr 11, 2012 at 2:45 PM, David Bruant <bruant.d at gmail.com> wrote:
Hi,
I am not part of TC39. I do not really have any opinion on whether it's a good or bad idea, but I have some questions (below):
Le 11/04/2012 20:11, Joey Schorr a écrit :
Greetings ES Discuss!
We (Joey Schorr and John Lenz, CCed) are some of the authors of the source map specification that is now implemented by WebKit and Firefox, as well as a number of compilers (Closure Compiler, GWT and soon CoffeeScript). Given that the specification is becoming a de-facto standard for mapping of code which is compiled to JS, we were curious if there was any interest in making it an actual standard under TC39. What's your interest in seeing this happening? What would be the benefit for you? For the spec?
It would encourage discussion and further development, as well as making it seem less like just a side project and more like a legit "good to have" in browsers (and other platforms that support JS)
The current specification can be found here: docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit , with a number of contributions from all the various parties involved. It seems like a good specification already (I can't see a copyright or licence. What's the status on that?). And you have two interoperable implementations apparently. What more would you need from a standardisation process?
Codifying it in some easy to find place and perhaps expansion of it at a later date.
Reaching out more browsers to adopt it?
That would certainly be one of the goals.
As much as I enjoy JavaScript, I'm aware of its limitations and I'm looking forward to more languages compiling down to JavaScript and your work is an excellent step towards having more of such languages, so thank you :-)
Our pleasure :)
Le 11/04/2012 20:11, Joey Schorr a écrit :
Greetings ES Discuss!
We (Joey Schorr and John Lenz, CCed) are some of the authors of the source map specification that is now implemented by WebKit and Firefox, as well as a number of compilers (Closure Compiler, GWT and soon CoffeeScript).
I have some more technical questions. Some are partially answered in the specification you linked to, but I'd be interested in a response here so that we can all discuss it.
If I want to start tomorrow a language that compiles down to JavaScript, what constraints do I need to fulfill to be compatible with your specification? Am I constrained in my language design? Do I have constraints in my compiler (do I need to ship in a certain way)?
I see that language neutral stack tracing is not supported, but what is your experience with the languages you currently support? How different can it be from language to language? (related: is it worthwhile to get inspiration in the work for other languages?)
On Wed, Apr 11, 2012 at 3:22 PM, David Bruant <bruant.d at gmail.com> wrote:
Le 11/04/2012 20:11, Joey Schorr a écrit :
Greetings ES Discuss!
We (Joey Schorr and John Lenz, CCed) are some of the authors of the source map specification that is now implemented by WebKit and Firefox, as well as a number of compilers (Closure Compiler, GWT and soon CoffeeScript). I have some more technical questions. Some are partially answered in the specification you linked to, but I'd be interested in a response here so that we can all discuss it.
If I want to start tomorrow a language that compiles down to JavaScript, what constraints do I need to fulfill to be compatible with your specification?
There has to be a 1 -> many relationship between the input language and JS
as output; in other words, you can produce many JS locations that map back to a single input location, but not vice versa (without losing some basic information).
Am I constrained in my language design?
It is more or less a pure mapping, so I have not seen any constraints in my experience (I've seen or worked on 4 languages mappings so far).
Do I have constraints in my compiler (do I need to ship in a certain way)?
No, you just need to provide the source map file with your code.
I see that language neutral stack tracing is not supported, but what is your experience with the languages you currently support? How different can it be from language to language? (related: is it worthwhile to get inspiration in the work for other languages?)
Stack tracing almost always requires additional information that is not in the map (such as how to collapse native stack frames, how to name the frames, etc). In my experience, to have excellent stack tracing, you need additional code which uses the source map + additional metadata to make the view much nicer. My own "perfect" stack trace mapping stored extra metadata in the source map and then used a Firebug extension to annotate the stack trace. Source maps support arbitrary metadata storage, so the user still needed just a single file. However, from languages which are much closer in input (Closure, for example), we have had stack trace mapping for errors for sometime and it works quite well (not perfectly, but Good Enough (TM)).
On Wed, Apr 11, 2012 at 12:42 PM, Joey Schorr <jschorr at gmail.com> wrote:
Do I have constraints in my compiler (do I need to ship in a certain way)?
No, you just need to provide the source map file with your code.
This 'provide' step is a bit of a headache since it means you have to coordinate your compiler with a server. Not an issue for the source map spec per se, but still something to plan for.
jjb
Correct; it would be great if we somehow solved the "bundling source map with source" problem.
I'm very glad to see this and I think it should be standardized by TC39. However, it should not be standardized as "part of the language", and so would result in a document distinct from Ecma 262. A good model is the way the internationalization track is proceeding.
Rather than create an entire new track just for source maps, I think this goes hand in hand with the need to standardize a debugging API. I suggest both be bundled into one new track.
Very strongly agree.
I also suggest that in-JavaScript diagnostics, such as access to stack information when errors occur, is also standardized by this track.
For example, there are bugs logged against all 3 major engines about the fact that onerror is basically useless because there's no way to get a stack trace:
https://bugs.webkit.org/show_bug.cgi?id=55092
https://bugzilla.mozilla.org/show_bug.cgi?id=355430
In each case, this has been acknowledged as a real problem, but it's fairly clear that at least the WebKit and Firefox bugs are stalled due to lack of standardization.
Also, more kudos to Joey and John for Source Maps :)
On Wed, Apr 11, 2012 at 5:08 PM, Charles Kendrick <charles at isomorphic.com>wrote:
Very strongly agree.
I also suggest that in-JavaScript diagnostics, such as access to stack information when errors occur, is also standardized by this track.
+1. These three all naturally go together.
On Wed, Apr 11, 2012 at 11:45 AM, David Bruant <bruant.d at gmail.com> wrote:
Hi,
I am not part of TC39. I do not really have any opinion on whether it's a good or bad idea, but I have some questions (below):
Le 11/04/2012 20:11, Joey Schorr a écrit :
Greetings ES Discuss!
We (Joey Schorr and John Lenz, CCed) are some of the authors of the source map specification that is now implemented by WebKit and Firefox, as well as a number of compilers (Closure Compiler, GWT and soon CoffeeScript). Given that the specification is becoming a de-facto standard for mapping of code which is compiled to JS, we were curious if there was any interest in making it an actual standard under TC39. What's your interest in seeing this happening? What would be the benefit for you? For the spec?
The current specification can be found here: docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit , with a number of contributions from all the various parties involved. It seems like a good specification already (I can't see a copyright or licence. What's the status on that?).
I've added a Creative Commons license to the document.
Greetings ES Discuss!
We (Joey Schorr and John Lenz, CCed) are some of the authors of the source map specification that is now implemented by WebKit and Firefox, as well as a number of compilers (Closure Compiler, GWT and soon CoffeeScript). Given that the specification is becoming a de-facto standard for mapping of code which is compiled to JS, we were curious if there was any interest in making it an actual standard under TC39. The current specification can be found here: docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit, with a number of contributions from all the various parties involved.
Thanks! Joey Schorr
Additional information:
Firefox implementation: mozilla/source-map WebKit implementation: code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/inspector/front-end/CompilerSourceMapping.js Tutorial for Chrome: www.html5rocks.com/en/tutorials/developertools/sourcemaps