- library availability: in Scala.js you have quite a number of core libraries available (see www.scala-js.org), but you also have direct access to JavaScript libraries

- interoperability with JS: Scala.js has its own TypeScript-like definition classes. But you can also interop in a dynamically typed way with the js.Dynamic type. In any case, the interop is very natural. Even the Scala syntax is close to JS syntax so method calls and property access just look the same.

- Code size: not exactly great, but manageable.

- Code speed: Scala.js has a very good optimizer that brings down typical macro benchmarks between 0.7x and 2x the time of the JS version (yes, 0.7x means it's actually faster!)

- Debugging capabilities: because of Source Maps, you basically step through your Scala.js code and step break points right inside your browser. All modern compile-to-JS languages have that.

Link to F#-to-JS compiler?

FunScript: https://github.com/ZachBray/FunScript/

WebSharper: http://www.websharper.com/

Blue Storm: https://www.assembla.com/spaces/bluestorm/wiki/

I got these from: https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

How about running Scala in multiple threads? And how about dealing with structurally-shared data?

You don't run code in multiple threads, but Scala's ExecutionContext is not about threads, but about asynchronous execution and JS is fine with that.

Also, all of Scala's collections, including the persistent ones are supported.

This (asynchronous execution) means we are forced to use cooperative multitasking, which is probably not good for reduced latency, and therefore bad for responsiveness (compare to the Windows 3.11 days where we were forced to use cooperative multitasking).

Yes, I know most JS programs today use asynchronous execution successfully in practice, but to use it as the basis of a language platform is not a good idea IMHO. Especially when it comes to UIs, which need the responsiveness.

EDIT: web-workers are not a solution, because you can't share large data-structures efficiently between web-workers.

But this applies to any javascript program (or compiled to javascript). If you have specific requirements then scala.js is not the tool. Scala is.

You can actually have multithreading by running Scala actors in web workers: https://github.com/sjrd/scala-js-actors

But you still can't use structurally shared data, which you need when you want to share large data-structures between threads.

If I understand you, I think it's a bit much to expect ScalaJS to somehow change the platform it is targeting, which is the browsers as accessed via Javascript (ie. without requiring plugins which would have made it DOA for most use cases). If browsers don't want threads that share data via Javascript control, and it appears they don't, and by design, then what is the alternative for ScalaJS? Same situation as with Javascript.

Mozilla is working on a type of array that can be shared.

The DOM is your structurally shared data. You just need to find a way to represent your data as (hidden) DOM nodes.

That actually doesn't work in this case, because Web Workers can't access the DOM.