ScalaJS fully optimised JS file

52 views
Skip to first unread message

Joseph Khafaji

unread,
Jul 9, 2018, 1:46:39 PM7/9/18
to Scala.js
Hi there,

I've started using ScalaJS at my current work project to share some business logic between the backend and the the front end. While everything seemed great and flawless, we are facing an issue that my front end developers are complaining about the large file size of the final fully optimised JS file being about 272KB.

Given that the codebase (at least for now), does not do much more than some mathematical calculations and not using any external libraries at the moment, so I am wondering if there are any ways to be able to further reduce the final fully optimised JS file? I know that the compiler performs dead code elimination but it seems to me that way too many things are added when we simply have a single statement that has a scala.math.BigDecimal in it

We are compiling this using the fullOptJS option only at present


Thanks in advance for the help

nik...@raquo.com

unread,
Jul 9, 2018, 9:09:53 PM7/9/18
to Scala.js
Sadly, there isn't much you can do about it.

- gzip the JS output when delivering over the network
- if you have JS dependencies you could extract those into a separate bundle which would improve caching. See ScalaJSBundler's various bundling modes.

Any real world Scala.JS app has a ~200KB tax from using various features from the Scala's standard library(collections, futures, etc.), that's pretty much unavoidable in practice.

This might improve with Scala 2.13 where the collection library (big part of the bundle size) is more modular, although I've read that it is turning out not as modular as originally desired.

There are a few open issues in the ScalaJS project to add support for code splitting and such, but those improvements will not reduce the raw output size, just cut it up into smaller pieces that can be loaded on demand.

Everything I've read about this issue says "this is a high level design tradeoff, and there is little opportunity for significant optimizations above the many optimizations that are already in place".

Now, disregarding the stdlib tax, you can do some things to make your own Scala code result in less generated JS code. That kind of optimization would be relevant for bigger applications. I don't know much about this, but I suspect even things like defining Scala native classes vs classes extending js.Object could affect the outcome at scale, although I'm not sure in which direction. I wish there was a comprehensive Scala.js performance guide... There are a few videos on youtube from a couple years ago where Sebastian showcases and explains Scala.js performance and optimizations on specific benchmarks though.

If anyone has a more educated view on any of this I'm all ears.
Reply all
Reply to author
Forward
0 new messages