3 ms·

If an exception is thrown in a Coffeescript program, does the runtime correctly report the original Coffeescript line numbers instead of that of the compiled Ja

If an exception is thrown in a Coffeescript program, does the runtime correctly report the original Coffeescript line numbers instead of that of the compiled Javascript? Things like this are the main reason why I'm wary of compilers that compile to another high-level language.

dreyfiz 16y ago
In practice, this isn't a problem. Coffeescript is more of an alternate syntax for Javascript than a different language. Sure it has some great sugar, but it's really easy to understand how that sugar translates into plain old Javascript. I'll usually have the .js file sitting in the next tab, being compiled live as I write code in the .coffee tab and hit save. Work like this for a little while and you'll learn to recognize which javascript is generated from which coffeescript really efficiently. coffee -cw -o js/ coffee/ Plus, your variable names in Coffeescript are well-preserved in the generated JS. Ultimately I find it harder to follow exceptions in my production javascript because of the obfuscation caused by minification (I use yuicompressor), so on my staging and development servers I point to a non-minified .js. Bottom line: try it, you'll like it!
dpritchett 16y ago
Your errors list JS line numbers. I didn't find it very difficult to mentally map the JS errors back to my Coffee source though - you get the same program structure and variable/method names before and after compile. Let's say you found a bug in line 41 of my JS source here: https://github.com/dpritchett/chatbox/blob/master/public/chatbox.js#L39 https://github.com/dpritchett/chatbox/blob/master/public/cha... Digging into the Coffee source shows the same short method with all the same identifiers and the same basic structure... just less boilerplate: http://dpritchett.github.com/chatbox/docs/chatbox.html#section-11 http://dpritchett.github.com/chatbox/docs/chatbox.html#secti...
- dreyfiz 16y ago
  Aha, your answer is more concise, and it addresses FooBarWidget's misapprehension more directly. Yes, "the runtime" is just the browser javascript engine.

dreyfiz 16y ago

In practice, this isn't a problem. Coffeescript is more of an alternate syntax for Javascript than a different language. Sure it has some great sugar, but it's really easy to understand how that sugar translates into plain old Javascript. I'll usually have the .js file sitting in the next tab, being compiled live as I write code in the .coffee tab and hit save. Work like this for a little while and you'll learn to recognize which javascript is generated from which coffeescript really efficiently. coffee -cw -o js/ coffee/ Plus, your variable names in Coffeescript are well-preserved in the generated JS. Ultimately I find it harder to follow exceptions in my production javascript because of the obfuscation caused by minification (I use yuicompressor), so on my staging and development servers I point to a non-minified .js. Bottom line: try it, you'll like it!

dpritchett 16y ago

Your errors list JS line numbers. I didn't find it very difficult to mentally map the JS errors back to my Coffee source though - you get the same program structure and variable/method names before and after compile. Let's say you found a bug in line 41 of my JS source here: https://github.com/dpritchett/chatbox/blob/master/public/chatbox.js#L39 https://github.com/dpritchett/chatbox/blob/master/public/cha... Digging into the Coffee source shows the same short method with all the same identifiers and the same basic structure... just less boilerplate: http://dpritchett.github.com/chatbox/docs/chatbox.html#section-11 http://dpritchett.github.com/chatbox/docs/chatbox.html#secti...

dreyfiz 16y ago
Aha, your answer is more concise, and it addresses FooBarWidget's misapprehension more directly. Yes, "the runtime" is just the browser javascript engine.