GregarianChild 2 months ago

Thank you Sébastien for your great work. Scala.js is one of the reasons I have been using Scala (for stuff that can be done in garbage collected languages).

What's your roadmap for Scala.js, any major innovations or changes in the pipeline? I have recently migrated a lot of code to Scala 3, and I'm about to begin a new project. So I am wondering if I should plan for interesting innovation in the Scala.js space, or if you are planning to be conservative.

  • sjrd 2 months ago

    Scala.js core itself, which I maintain, does not need much innovation. We support all of Scala, and interact with any JavaScript library. That's what the core promises.

    If you want to compare to Scala 3, it's worth pointing out that you can use Scala.js with any Scala version >= 2.12.2. In particular, you can use it with Scala 3 and benefit from all its innovations. ;)

    Innovation comes mainly from libraries, notably UI libraries. Laminar ( is a great example.

    In terms of roadmap, we are mostly working on "boring" stuff: improving performance (of the generated code, and of the linker), fixing bugs when they get reported, etc.

    Perhaps, when Wasm gets more features for deeper interoperability with JavaScript (manipulating objects notably), we will take another look at targeting Wasm. People usually expect all languages to target Wasm now, "because it's fast". Truth is, it's fast for languages with linear memory. There is no evidence yet that it will be fast for memory-managed languages with objects and virtual dispatch.

sjrd 2 months ago

Author of Scala.js and of the post here. AMA.

  • halfmatthalfcat 2 months ago

    How does the Scala.js community reach more developers who want type safety (and probably already use Typescript) yet still want the nimbleness of the Javascript community?

    I've been a part-time Scala developer for a long time and have trouble choosing Scala.js for any frontend project because of SBT, missing type facades for npm packages and just other general friction of using a non-web-native language for frontend development.

    I want to see Scala.js succeed but I feel unless some of the major adoption pain points are addressed (which JDG addressed recently[1] about the Scala ecosystem generally) it will continue to be an ultra-niche project.


    • sjrd 2 months ago

      You can get facade types for any JavaScript library using . If types exists in the library itself or in DefinitelyTyped, you can use them.

      sbt is not mandatory. All the build tools commonly used in Scala projects support Scala.js. For example, Maven or Mill. That said, you cannot use `npm` directly to build Scala.js libraries, indeed. npm does not have the infrastructure to talk the incremental Scala compiler, which is a must for fast development cycle.

      We're trying to get a bit closer to JS tooling, notably with better tutorials and tooling targeting the like of Vite. But at the core, there is Scala tooling involved.

    • nikitaga 2 months ago

      I've been working with Scala.js for several years and I have no idea why JDG chose those four bullet points as important weaknesses of Scala.js. Those weaknesses seem overstated, they just aren't the things I had to ever worry about, even when I was new to Scala / Scala.js. Like, I'm not good at sbt in general, but I never had problems with Scala.js build setup, even when I started cross-publishing libraries for Scala and Scala.js

  • pubg 2 months ago

    What functional overlap is there between TypeScript and Scala.js?

    • sjrd 2 months ago

      TypeScript provides static types for JavaScript. Not just the language, but its idioms, its way of writing programs.

      Scala.js is first Scala. That means you favor a style with immutable data, work with the great collection library of Scala all the time, and in general follow the idioms and way of writing programs that Scala offers.

      Speaking in very broad terms, I could say TypeScript stays more in the "imperative" paradigm, while Scala goes more "functional". But of course in both languages, you will find people everywhere on the imperative<->pure FP spectrum. The center of gravity of TypeScript will be more on the imperative side and that of Scala, more on the FP side.

      Also, Scala aims to have a sound type system. If your code compiles, it won't run into certain categories of bugs. TypeScript, by design, does not give any such guarantee.

  • no_wizard 2 months ago

    How big is an application written in Scala.JS on average? My sense is this is a very heavy runtime

    • sjrd 2 months ago

      There's no runtime. The Scala language is compiled to JavaScript. There is no interpreter in JavaScript that runs the Scala code.

      There is a cost for the standard collections library (from 100 to 200 KB depending on what you use) but otherwise you only pay for what you use.

      • nikitaga 2 months ago

        It's also worth noting that Scala / Scala.js includes lots of features that JS developers use a plethora of third party libraries for.

        For example JS has no immutable collections built-in, so you'd need something like immutable.js (65KB) which is annoying to use because it's not integrated with other libraries or language features, whereas Scala libraries obviously work well with Scala collection types.

        Or take Scala's implicits vs React.js context. The latter is what you need to invent when your language has no concept of implicit parameters, and it's a poor, library-specific, substitute.

    • vvillena 2 months ago

      It's in the order of "hundreds of kilobytes" (a basic Hello World starts at about 100 KB, the size of a fully optimized Scala standard library). The resulting code is 100% Javascript, so there's no runtime cost during execution.

er1cpeters 2 months ago

Sébastien has been an amazing steward of Scala.js, very helpful and approachable when creating PRs and getting feedback, thanks so much mate!

MasterScrat 2 months ago

I had no idea this was a thing! and I learned Scala from Prof Odersky himself ;-)

What are the selling points of Scala.js vs modern JavaScript/TypeScript?

  • nikitaga 2 months ago

    Typescript is not actually very type safe, and although they sometimes make small improvements on that front, the unsafety is fundamentally very much by design, they prioritize supporting all the dynamic Javascript idioms over type system soundness, it's even in their docs somewhere.

    Scala is a very nice and expressive language with a much safer type system. It lets you program in a very reasonable mix of FP and OOP without going to the extremes of either approach. You're not beholden to weird Javascript idioms yet you can still easily use JS libraries (we have ScalablyTyped which is like Typescript's DefinitelyTyped).

    Typescript is generally well loved partly because for many Javascript developers it is their first and only statically typed language, so they tend to attribute the benefits of static typing to Typescript, and attribute the problems specific to Typescript to static typing in general. This makes it hard to sell Scala.js to this audience, but I still encourage JS devs to try other statically typed languages, maybe you'll like them much more.

  • sjrd 2 months ago

    Probably all the same selling points that Scala/JVM has over Java or Kotlin. The main one would be favoring a coding style with immutable data, only reaching for mutability when necessary. If you like that style, Scala.js will help you write in that style.

    See also one of my other answers with some more comparisons.

no_wizard 2 months ago

How big is an application written in Scala.JS on average? My sense is this is a very heavy runtime