LiveScript is more like a functional sugar coat over JS, so it preserves most JS core semantics. Especially strict evaluation and duck typing. Because of that, i think it is much easier to do the conversion from the JS world to LiveScript, and viceversa.
Introducing Laziness, pureness and static typing into the JS world is a much bigger challenge. I'd love to see some of these efforts take off; especially Elm, which is even more ambitious, as it not only provides a safer alternative to JS, but also to the DOM model and HTML altogether.
The biggest problem i see these projects facing is the abstraction gap. As the abstraction over JS/DOM that they provide is much bigger than, say, CoffeeScript of LiveScript, when that abstraction breaks and you have to dig into the generated JS/DOM world, it's very painful. And this is a necessary pain every time things don't work as expected and you need to debug in the browser. I think that for these projects to be successful efforts like source maps are crucially important. But for projects as ambitious as Fay or Elm, i think we need even better debugging tools; some environment where we can debug entirely within the abstraction layer that these languages provide, and make the cases where you have to resort back to JS much more uncommon.
LiveScript compiles almost 1 to 1 to JavaScript and has no runtime, making it easier to debug and comprehend for JavaScript programmers. You can access and use any JavaScript library without having to resort to a special syntax. For JavaScript programmers, it may be easier to use LiveScript. For Haskell programmers, it may be easier to use Fay.
I think many JavaScript programmers are looking for JavaScript (CoffeeScript) + functional programming rather than something purely functional as it allows them to use all that they've learned and mastered from JavaScript (often in an enhanced way) while using functional concepts as they learn them.
