Hacker News Reader

Comment by bad_user | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com