4 ms·

How human-readable is the compiled javascript?

adambard 13y ago
Surprisingly. Where a construct really has no JS analogue, the structure is still mostly maintained and the extra bits are packed into a function that appears right below the code block.
unoti 13y ago
It's very human readable. Look for yourself-- there are side by side examples of coffeescript and the JS it generated on the front page http://coffeescript.org/ http://coffeescript.org/ . The generated JS is actually a great way to learn about some best practice ways of using Javascript in ways that avoid common pitfalls. I started using CoffeeScript shortly after reading "Javascript, The Good Parts" and the ideas from that book are basically automatically implemented.
- wwweston 13y ago
  It's readable (admirably so), but I don't know about reading the output for best practices -- it's not idiomatic JS and not meant to be (however readable), it's meant to be a formal equivalent of the CoffeeScript syntax.
  - unoti 13y ago
    The way that it creates closures for enclosing variables for packages is idiomatic and best practice. The way that it handles looping is idiomatic for avoiding certain kinds of common pitfalls. The way that it creates "that" variables for temporarily holding on to "this" for a while is idiomatic. There are a bunch of things like that that it does automatically.
    - wwweston 13y ago
      > The way that it handles looping is idiomatic for avoiding certain kinds of common pitfalls. Unless you're using native (or shim'd) map and similar constructs instead. (Or, for that matter, if you're otherwise used to writing code where block scope isn't the rule.) > The way that it creates "that" variables for temporarily holding on to "this" for a while is idiomatic. Unless you're using bind instead. I suppose it's true enough that people can in fact learn good things from the CS compiler output. But the JS that CS writes is not necessarily the JS an experienced dev would write or would have to write to achieve the same goals -- even taking into account the principles behind "best practices."
      - unoti 13y ago
        The same can be said for any higher level language being compiled into any lower level language or machine code. It's similarly true that an optimized C compiler won't always write the best code in a best practice way. Also true: no matter how good something is, there'll always be someone eager to put it down.
        wwweston 13y ago
        > an optimized C compiler won't always write the best code in a best practice way. Aaand, therefore, you might not suggest to people that a good way to learn to write good asm would be to study the output of a C compiler. However educational that experience might be. > Also true: no matter how good something is, there'll always be someone eager to put it down. Not sure where this is coming from unless you think we're having a conversation about the merits of a language, instead of the merits of learning another language from the output of a transpiler.
      - deleted 13y ago
        [deleted]

Surprisingly. Where a construct really has no JS analogue, the structure is still mostly maintained and the extra bits are packed into a function that appears right below the code block.

unoti 13y ago

It's very human readable. Look for yourself-- there are side by side examples of coffeescript and the JS it generated on the front page http://coffeescript.org/ http://coffeescript.org/ . The generated JS is actually a great way to learn about some best practice ways of using Javascript in ways that avoid common pitfalls. I started using CoffeeScript shortly after reading "Javascript, The Good Parts" and the ideas from that book are basically automatically implemented.

wwweston 13y ago
It's readable (admirably so), but I don't know about reading the output for best practices -- it's not idiomatic JS and not meant to be (however readable), it's meant to be a formal equivalent of the CoffeeScript syntax.
- unoti 13y ago
  The way that it creates closures for enclosing variables for packages is idiomatic and best practice. The way that it handles looping is idiomatic for avoiding certain kinds of common pitfalls. The way that it creates "that" variables for temporarily holding on to "this" for a while is idiomatic. There are a bunch of things like that that it does automatically.
  - wwweston 13y ago
    > The way that it handles looping is idiomatic for avoiding certain kinds of common pitfalls. Unless you're using native (or shim'd) map and similar constructs instead. (Or, for that matter, if you're otherwise used to writing code where block scope isn't the rule.) > The way that it creates "that" variables for temporarily holding on to "this" for a while is idiomatic. Unless you're using bind instead. I suppose it's true enough that people can in fact learn good things from the CS compiler output. But the JS that CS writes is not necessarily the JS an experienced dev would write or would have to write to achieve the same goals -- even taking into account the principles behind "best practices."
    - unoti 13y ago
      The same can be said for any higher level language being compiled into any lower level language or machine code. It's similarly true that an optimized C compiler won't always write the best code in a best practice way. Also true: no matter how good something is, there'll always be someone eager to put it down.
      - wwweston 13y ago
        > an optimized C compiler won't always write the best code in a best practice way. Aaand, therefore, you might not suggest to people that a good way to learn to write good asm would be to study the output of a C compiler. However educational that experience might be. > Also true: no matter how good something is, there'll always be someone eager to put it down. Not sure where this is coming from unless you think we're having a conversation about the merits of a language, instead of the merits of learning another language from the output of a transpiler.
    - deleted 13y ago
      [deleted]