DEV Community

Discussion on: My Four Year Quest For Perfect Scala.js UI Development

Collapse
 
yurique profile image
Iurii Malchenko

We'd heard that Scala was going to die for many years now, but it's still here and not going anywhere. I believe it's as good as it ever had been (as a language, community and ecosystem), and it will get even better with Scala 3 (well, we're yet to see if it actually does, but I'm betting on it :) ).

Javascript programmers are very hard to please.

In this post Nikita described why all the attempts to please JavaScript programmers were not good enough for him. And I can put my signature under each word in this post.

So instead of accepting the state of things, Nikita has built something great, with a language he liked, using the techniques that actually make sense. And I personally can't stress enough how much I'm grateful for having this tool now.

And if Scala.js or Laminar don't become the "next big thing" or the next "go-to framework of the week" - I couldn't care less. I'm doing quite a bit of React/TS at work, and every time I do - I'm reminded how much I dislike doing it. Whenever I get to use Laminar - I'm a happy developer, using a reliable tool (scalac) and a well-designed API/DSL (Laminar). ReasonML, Elm are probably good, too, definitely better that JavaScript (and I guess TypeScript), but if they use virtual DOM - I pass.

Collapse
 
theodesp profile image
Theofanis Despoudis • Edited

I agree, TS looks good from the outside but when you start working with it, you can taste the sourness.

I've tried Elm but It felt really weird.

Now days I'm testing ReasonML and it looks like it positions itself in the middle ground. React Developers will find it very familiar and it has good support for common libraries. Javascript interop is good and the type system is better than Typescript. It doesn't go in the extremes like Haskell and it offers a good compromise.

I've had a bad experience with Scala.js and Scala in general just because of the documentation (or the lack of it). Mainly because of the symbolic soup and the unnecessary DSLs. Cats, Shapeless, ZIO are all unnecessary abstractions in the frontend. You need something simple and effective but the language oversubscribes. I remember trying out Udash framework and was chocked by it's complexity.

Don't expect the average Javascript dev to spend 3 months trying to understand how to work with SBT or anything more complicated.

I've spend more than a month on each of the underscore.io/training/ books and after that I had constant headaches.

At the end of the day IMHP it's not worth it. There is no point abstracting the hell out of it. Scala is more suitable for backend development or someone that have invested lots of time with the language and doesn't want to part with it.

Let's not talk about convincing your manager to switch to Scala.js unless he thinks you are telling jokes.

However I could try out Laminar if it had good documentation. The key thing here to sell smart and make it easy to work with. More examples here would help.

For instance a ToDo list app, more 2 minute tutorials like this one. There are tons of people writing about React. This needs to be done with Scala.js if people want to take this seriously.

Thread Thread
 
yurique profile image
Iurii Malchenko • Edited

I've had a bad experience with Scala.js and Scala in general just because of the documentation (or the lack of it). Mainly because of the symbolic soup and the unnecessary DSLs. Cats, Shapeless, ZIO are all unnecessary abstractions in the frontend. You need something simple and effective but the language oversubscribes. I remember trying out Udash framework and was chocked by it's complexity.

Laminar not having these problems is the reason why I initially committed to learning it.

I did try Udash, React scala.js wrapper, and other things - and it is true that they are overly complicated.

Having been using Scala as my main language for years, I had really tough times trying to figure out those libs and understand how to use them. And I eventually give up trying, with each of them.

Don't expect the average Javascript dev to spend 3 months trying to understand how to work with SBT or anything more complicated.

sbt doesn't have to be complicated.

Though build definitions for large projects indeed tend to become complicated eventually (to the extent when one really has to understand sbt to navigate there). On the other hand, the things have improved a lot in recent years, with sbt itself getting better, as well as people getting better at understanding and not abusing it.

But for a scala.js frontend project, the build would be like a dozen lines, which one would take from a project template (one is coming soon) and likely not ever need to update or modify (except bumping up the dependency versions).

And it will just work - no need to install/manage node, npm, npx, and all the other WTFs. Even on a clean system two years later (unless maven central burns down). However, I do use webpack together with sbt (sbt to produce the resulting js, and webpack for the rest of it, like css and bundling). And honestly, I personally find webpack to be more complicated than sbt.

Also, there's Mill, which is simpler than sbt and supports scala.js out of the box. Though I went back to sbt, after all.

I've spend more than a month on each of the underscore.io/training/ books and after that I had constant headaches.

Well, Scala is a language of it's own kind, in a way. But it's actually a simple one (with a grammar definition smaller than Java's).

What gets complicated is libraries, that introduce different concepts and abstractions (like cats for FP and CT; or cats-effect for lawlful pure IO). But it's not the language that is complicated. The language is just expressive enough to allow for all these additional concepts and abstractions. And I believe it worth investing in learning and using those, regardless of language. Most people don't care, but I guess that is not my problem :)

I don't know how things are with resources for training/introducing newcomers to Scala nowadays, but back in the day I've been finding that it was indeed not perfect. But I know for sure that there are many more courses and books on Scala today (and oh boy I wish I had them 7 years ago). To name a few:

I did read the underscore.io books. I don't think I found them to be very helpful or insightful for me. Except the shapeless one :) But I knew Scala well already before reading it.

Let's not talk about convincing your manager to switch to Scala.js unless he thinks you are telling jokes.

Yes, that's the bitter reality, unfortunatelly. I wouldn't even try. In regular business, regular project - the "market proposition of devs" dictates and limits the options. But whenever I'm doing something on my own - I pick laminar.

However I could try out Laminar if it had good documentation.

I find Laminar's documentation to be pretty good (as well as Airstream's).

More examples here would help.

For instance a ToDo list app,

github.com/raquo/laminar-examples ;)

more 2 minute tutorials like this one. There are tons of people writing about React.

It's hard to compete (not to say that anyone is trying to compete here) with React (with FaceBook pouring money into it) or Angular (with Google).

But we might get more Laminar content like that eventually, who knows? ;)