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.