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.
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.
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.
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.
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/ . 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.
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.
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.
> 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."
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.
> 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.
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.
Not saying not to use it, but my use case has to overcome that question.