scalajs-react VS Chimney

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.

But yeah, I wonder if using a tool for case classes conversion like https://github.com/scalalandio/chimney would help in managing those ADT hierarchies for DB/business logic/web layer/etc.

Hello, if you have some nice examples could you please check if it's something that would fit any of issues planned for 0.7.1 or create a new one?

Perhaps, https://github.com/scalalandio/chimney would leverage it.

Thankfully, there are some solutions that can help reduce the boilerplate of these manual conversions. For instance, chimney : https://scalalandio.github.io/chimney/

I want to upgrade one project to Scala 3.1, but I'm using the macro heavy chimney (https://github.com/scalalandio/chimney) to reduce the boilerplate, which is not available for Scala 3 yet. My idea was to copy and paste the code that chimney generates on 2.13, and after that uncomment the uses of chimney for now.

In my $dayjob we originally used Scala, but I pushed for a couple of new services to be written in TypeScript/Node as it was really hard to hire Scala developers. I'd say it worked well, we even took a somewhat functional approach to building things. We tried fp-ts but that was a bit hardcore (when you are trying to hire TypeScript developers who don't know functional programming), so just built Either and Option types which provided 99% of what we needed.

There are still a few things I miss though:

* Pattern matching and exhaustive checking. Using a switch statement it is possible to define a function that can emulate the compile-time exhaustive checking, but it's still rather weak compared to what you can do in Scala.

* Implicits. Being able to define something that can convert say a UUID to a String or vice versa automatically just feels like magic, especially when dealing with data from third party systems.

* Compiler macros and metaprogramming. It enables tools like Chimney (https://scalalandio.github.io/chimney/) to be built, which I don't think are possible with TypeScript right now.

Converting between these classes can add some boilerplate, but luckily there are libraries like https://github.com/scalalandio/chimney that make it much easier.