5 ms·

When looking at languages like LiveScript (or CoffeeScript) I say to myself: "Javascript has been around for 18 years, how long will this be around for?" Not s

by ambirex 13y ago

When looking at languages like LiveScript (or CoffeeScript) I say to myself: "Javascript has been around for 18 years, how long will this be around for?" Not saying not to use it, but my use case has to overcome that question.

bayesianhorse 13y ago
I usually introduce CoffeeScript as "shorthand for best-practice Javascript". The big weakness of CoffeeScript IMHO currently is the weak organizational structure of the community. I don't see a clear path where the project is going, and already there are forks/parallels like livescript and IcedCoffeeScript, both with their own strengths. The output is usually more readable than a lot of JQuery plugins I've seen ;-) I regard CoffeeScript and its cousins as tools rather than frameworks or languages.
noelwelsh 13y ago
With Coffeescript (I don't know about Livescript) the compiled output is close enough to hand-written Javascript that, if Coffeescript suddenly disappeared into a black hole, you could use the compiled output as source if needed.
- adambard 13y ago
  Livescript is a fork of Coffeescript, and LS 1.2 purports to have improved the JS output for readability, so I think you'd be ok.
  - AndyKelley 13y ago
    Livescript is technically a fork of coco[1] which is a fork of Coffeescript. [1]: https://github.com/satyr/coco/ https://github.com/satyr/coco/
jashkenas 13y ago
One of the nice bonuses of targeting lowest-common-denominator JavaScript is that it makes things extremely compatible, and durable. Even if all of the world's copies of the CoffeeScript compiler disappeared tomorrow afternoon, in between sips of tea, your compiled code would still run on every JS runtime (back to IE6), and would still be compatible with all other JavaScript libraries, and future versions of CoffeeScript as well.
vinceguidry 13y ago
If it goes away, just compile the source to javascript and maintain that.
- RyanMcGreal 13y ago
  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.

by ambirex 13y ago

bayesianhorse 13y ago

I usually introduce CoffeeScript as "shorthand for best-practice Javascript". The big weakness of CoffeeScript IMHO currently is the weak organizational structure of the community. I don't see a clear path where the project is going, and already there are forks/parallels like livescript and IcedCoffeeScript, both with their own strengths. The output is usually more readable than a lot of JQuery plugins I've seen ;-) I regard CoffeeScript and its cousins as tools rather than frameworks or languages.

noelwelsh 13y ago

With Coffeescript (I don't know about Livescript) the compiled output is close enough to hand-written Javascript that, if Coffeescript suddenly disappeared into a black hole, you could use the compiled output as source if needed.

adambard 13y ago
Livescript is a fork of Coffeescript, and LS 1.2 purports to have improved the JS output for readability, so I think you'd be ok.
- AndyKelley 13y ago
  Livescript is technically a fork of coco[1] which is a fork of Coffeescript. [1]: https://github.com/satyr/coco/ https://github.com/satyr/coco/

jashkenas 13y ago

One of the nice bonuses of targeting lowest-common-denominator JavaScript is that it makes things extremely compatible, and durable. Even if all of the world's copies of the CoffeeScript compiler disappeared tomorrow afternoon, in between sips of tea, your compiled code would still run on every JS runtime (back to IE6), and would still be compatible with all other JavaScript libraries, and future versions of CoffeeScript as well.

vinceguidry 13y ago

If it goes away, just compile the source to javascript and maintain that.

RyanMcGreal 13y ago
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.