Scala.js VS Play WS

Links: - https://dotty.epfl.ch/ - https://scala-native.org/en/stable/ - https://www.scala-js.org/ - https://typelevel.org/ - https://zio.dev/ - https://github.com/scala-native/scala-native/pull/3120 - https://github.com/lampepfl/dotty/pull/16517 - https://dotty.epfl.ch/docs/reference/experimental/index.html - https://scala-cli.virtuslab.org/ - https://scalameta.org/metals/ - https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html - https://www.scala-lang.org/blog/2023/04/18/faster-scalajs-development-with-frontend-tooling.html - https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html

> Scala choices were directly dictated by JVM

Initially, yes. But Scala has evolved beyond the JVM, with Scala.js [1] being rock-solid, and Scala Native [2] under development. Neither are truly hampered by the initial JVM roots of Scala.

> Scala gives you a better horse

Weird analogy ;)

[1] https://www.scala-js.org/

Have you had a look at Scala.js yet? Also see "Scala.js for JavaScript developers." and "Tour of Scala."

What does that have to do with language size? It also compiles to js https://www.scala-js.org/ and native https://scala-native.org/en/stable/

Here's a hybrid option: Scala.js. Yes, it is about building web applications but in Scala. You can retain the HTML/CSS/JS knowledge you have but build web applications from a typesafe and powerful language: Scala

The compiler crash in question affects another feature that we would like to merge for the benefit of all users, namely https://github.com/scala-js/scala-js/pull/4735. Keeping 2.11 means that testing and shipping that feature is much more difficult, even for 2.12+ users only. It's not just "to fix a compiler crash".

TS is more in the "mixed feelings" department, imho.

I would take Scala.js anytime instead. (If I would need to do front-end ever again).

https://www.scala-js.org/

[0] https://www.scala-js.org/ [1] https://lampwww.epfl.ch/~doeraene/thesis/doeraene-thesis-2018-cross-platform-language-design.pdf

Take a look at https://github.com/playframework/play-ws build.sbt. it is a scala lib built with sbt-assembly to shade dependencies and avoid binary incompatibility. That is the only reason to build a lib with sbt-assembly.

In this example, the code uses Play WS Standalone as a REST client to fetch JSON containing a UUID. Play WS has an asynchronous, non-blocking API based on Future, so you need to provide an ExecutionContext via Akka. That's all the boilerplate at the beginning of this example. Sometimes it will be done for you as when you use Play WS in the context of Play Framework. Nonetheless, you should be aware it has to happen somewhere.