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.
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 (https://laminar.dev/) 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.
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.
You can get facade types for any JavaScript library using https://scalablytyped.org/docs/readme.html . 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.
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
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.
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.
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.
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.
> 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.
Actually, I have had some success onboarding js devs into sjs, until now, all of them have mentioned that it is hard to go back to js/ts because the type-safety just can't be compared (I even presented this at a conference last December).
These are some comparisons on js vs sjs code on top of react (js on the left, sjs on the right):
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.
Having worked with sjs for some years, sjs code size is usually negligible if you compare it to the sizes from its dependencies. I commonly that the app weights ~1-3mb but gzip compression helps quite a lot, reducing the compresed version to ~200-500kb.
To get concrete examples, let's focus on this app [1] that has an admin portal (based on react-admin and scalajs-react) and a web portal (based on react, slinky, and, material-ui 3).
The web app [2] weights ~2.5Mb, ~550kb compressed [3] (yes, mui is heavy but this wouldn't be too different on the js version).
The admin app [4] weights ~2Mb, ~570kb compressed [5] (react-admin is heavy too).
To get another example, check this simple sjs games [6] that had no js dependencies but a single sjs dependency, bundle is ~630kb, ~100kb compressed [7].
It is worth mentioning that none of these app got any effort on reducing its bundle size (worth exploring some day). Given the strong-compiler and the lack of reflection, Scala.js can perform very nice optimizations to remove any code that isn't necessary to the app execution.
While module splitting was introduced by sjs 1.3.0 [1], the apps I have linked do not use it just yet (well, technically, the games page uses it but it is a single page loading everything, so, no real benefit from it).
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.
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 (https://laminar.dev/) 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.
Author of Scala.js and of the post here. AMA.
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.
[1] https://degoes.net/articles/scala-resurrection
You can get facade types for any JavaScript library using https://scalablytyped.org/docs/readme.html . 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.
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
What functional overlap is there between TypeScript and Scala.js?
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.
How big is an application written in Scala.JS on average? My sense is this is a very heavy runtime
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.
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.
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.
Sébastien has been an amazing steward of Scala.js, very helpful and approachable when creating PRs and getting feedback, thanks so much mate!
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?
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.
> 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.
Actually, I have had some success onboarding js devs into sjs, until now, all of them have mentioned that it is hard to go back to js/ts because the type-safety just can't be compared (I even presented this at a conference last December).
These are some comparisons on js vs sjs code on top of react (js on the left, sjs on the right):
- Hello World: https://pbs.twimg.com/media/FngeaoraAAAr2r0?format=jpg&name=...
- Timer: https://pbs.twimg.com/media/FnlL1PjaMAEL-zJ?format=jpg&name=...
- ReCAPTCHA usage: https://pbs.twimg.com/media/FnvY_hAagAIjWF5?format=jpg&name=...
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.
How big is an application written in Scala.JS on average? My sense is this is a very heavy runtime
> My sense is this is a very heavy runtime
It all depends on what you consider to be heavy.
Having worked with sjs for some years, sjs code size is usually negligible if you compare it to the sizes from its dependencies. I commonly that the app weights ~1-3mb but gzip compression helps quite a lot, reducing the compresed version to ~200-500kb.
To get concrete examples, let's focus on this app [1] that has an admin portal (based on react-admin and scalajs-react) and a web portal (based on react, slinky, and, material-ui 3).
The web app [2] weights ~2.5Mb, ~550kb compressed [3] (yes, mui is heavy but this wouldn't be too different on the js version).
The admin app [4] weights ~2Mb, ~570kb compressed [5] (react-admin is heavy too).
To get another example, check this simple sjs games [6] that had no js dependencies but a single sjs dependency, bundle is ~630kb, ~100kb compressed [7].
It is worth mentioning that none of these app got any effort on reducing its bundle size (worth exploring some day). Given the strong-compiler and the lack of reflection, Scala.js can perform very nice optimizations to remove any code that isn't necessary to the app execution.
- [1]: https://github.com/wiringbits/scala-webapp-template/
- [2]: https://template-demo.wiringbits.net
- [3]: https://raw.githubusercontent.com/wiringbits/scala-webapp-te...
- [4]: https://template-demo-admin.wiringbits.net (credentials being demo/wiringbits)
- [5]: https://github.com/wiringbits/scala-webapp-template/blob/mas...
- [6]: https://github.com/wiringbits/scala-js-games
- [7]: https://raw.githubusercontent.com/wiringbits/scala-js-games/...
Does it do any smart lazy loading cans/or code splitting based on entry points into different functionality of the application?
This is the kind of optimization you can get from compilers like this, esp. leveraging the closure compiler
While module splitting was introduced by sjs 1.3.0 [1], the apps I have linked do not use it just yet (well, technically, the games page uses it but it is a single page loading everything, so, no real benefit from it).
[1]: http://www.scala-js.org/news/2020/10/16/announcing-scalajs-1...
Yes, it does. This is what Dynamic Imports are for. See https://www.scala-js.org/doc/project/module.html#dynamic-imp...