Scala.jsFiddle: TodoMVC
scala-js-fiddle.com
scala-js-fiddle.com
The X-to-Javascript tools work best if the language actively embraces the Javascript roots (TypeScript, CoffeeScript, etc) instead of trying to hide it in abstractions. Sure, it's convenient to be able to use Scala collections but do you really need to? Granted, this can be said of anything ("Do you need to use C when there's asm?") but whenever you'll do something complex in a language like this: At some point you'll have to debug, and that's the point where you need to somewhat understand the underlying abstraction.
I don't think this is true. X-to-Javascript tools work best when they are well-designed to fit both the norms of the original language and to solve the problems of building user interfaces. JavaScript does that, so embracing JS gets you lots of libraries, patterns, and design experience for free.
But it's also possible to create good designs in other ways. I'm quite fond of ClojureScript, with its immutable data and pure functions. But using it with the mutable DOM patterns forced me to choose between speed and writing idiomatic Clojure. Now that we have ReactJS, I can write my interface as a mostly-pure function over data, and have React do the heavy lifting of figuring out how to update the DOM quickly.
This was a much longer route to get to a good design, but I think it's a much nicer way to build web UIs.
The problem with Scala.js is it doesn't seem to have this same level of design inspiration. It has the nice parts of Scala, and the warts of the DOM, and the two don't even fit together the way that JS fits the DOM.
JavaScript really isn't hard, trying to avoid writing it by writing a more complex language which gives you more JavaScript than you would have had anyway really can't ever be a win surely?
I've had massive business value from writing code in a more type safe language and then transpiling it into a number of other languages, including javascript.
As for the haters, there's no real reason at this stage to worry about "why would you use this for that" - people said the same thing about Java server-side (it's slow and on servers, cross-platform doesn't matter), Javascript server-side (it's single-threaded and clunky and people only use it because they are forced to), C# for iOS development (but it's from Microsoft), etc, etc.
In my mind, what Om is bringing to React is idiomatic state management with Clojure semantics. In js I think the local state model promoted by React is reasonable.