SJRD, Would you also add a bit more info about how this size increases? I haven't cared much but it seems from your comments that the slope should be much less once you reach 90kb.
Since Scala.js (like CLJS) is backed by Google Closure Compiler, I bet you'll also reach for the Closure Library for a lot of stuff where one might reach for JQuery or equivalent otherwise. The stuff in there is of course optimized for Closure Compiler, and slims down quite well.
In ClojureScript, GCC is a user-visible feature of the toolchain, so users are encouraged to use GCC-compatible libraries and the Closure Library in particular.
In Scala.js, GCC is really an implementation detail of the toolchain, and its constraints are completely abstracted away from the user. This does not really encourage using GCC-oriented libraries like the Closure Library.
The two approaches each have pros and cons:
* CLJS' approach allows tree shaking across the CLJS code and the GCC-compatible libraries that are used. However, it makes it more difficult to use libraries that do not comply with GCC's Advanced Optimizations requirements, as one needs to declare the proper `externs` files.
Admittedly, I'm using shadow-cljs as my go-to compiler (so I'm not sure what the state of vanilla is), but all I do is yarn add <package>, and then require it in the file where I want to use it, and interact with it as if it were any other library.
Though it is true of shadow-cljs as well that it doesn't try to tree-shake external (non-CLJS/Closure) libs by default, though it will do it for project code and Clojure libraries.
Once Scala.js supports lazy loading of modules (hopefully soon after 1.0), the size issue will have significantly less practical impact.