3 ms·

I have to say this seems like an extremely elaborate hammer for a tiny nail. The question is: If you have an application that is much less trivial than this one

I have to say this seems like an extremely elaborate hammer for a tiny nail. The question is: If you have an application that is much less trivial than this one, will the complexity scale accordingly or will it only increase gradually? 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.

asolove 13y ago
> The X-to-Javascript tools work best if the language actively embraces the Javascript roots 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.

asolove 13y ago

> The X-to-Javascript tools work best if the language actively embraces the Javascript roots 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.