scalajs-react VS Scala.js

Then there's scalajs-react, which can be integrated with existing React ecosystem, but it's just sooo compex: macros, 5-6 type parameters, hundreds and hundreds of cryptic types. We decided to stick with TypeScript instead.

Or the OG React Scala.js library: https://github.com/japgolly/scalajs-react

Japgolly has put a ton of time and care into https://github.com/japgolly/scalajs-react which is a complete React binding in scalajs. This paired with something like Diode (https://github.com/suzaku-io/diode) and you get a full frontend solution in scalajs.

We've got server-side rendering with scalajs-react and scala-graal. Here's a tutorial if anyone's interested. What's really cool about scala-graal is that it has some pretty cool caching so that even with dynamic inputs, you can render pages in nanoseconds (as opposed to 10+ or even 100+ ms).

You can use React with Scala.js, and also most other common JS libraries. Or you can use a Scala.js specific library like Laminar, which I haven't tried myself but it looks nice.

I don't have a lot of experience with it, but many seem to be very pleased with it. Interop with JS is good and you can use React and other common JS libraries, but there is also Scala.js specific frameworks like Laminar.

https://github.com/japgolly/scalajs-react is pretty heavily used as well, and fairly active as a project. In short, building it off of that wouldn't be a huge risk over typescript, and might even be a net win in the long run, as you could re-use some stuff from the backend in the front-end.

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