How to handle large js files in a Scala.js React.js application?

Question

How do we handle app-jsdeps.js and app-opt.js in a large Scala.js React applications with a lot of js code & dependencies ?

I've build my first web application using @japgolly scalajs-react using @ochrons spa-tutorial example but even after optimising it the size of app-jsdeps.js (only 10 external JS deps) and app-opt.js file is around 900kb which is taking about 8 seconds to download before the page loads.

What do we usually do in this situation ?

• Do we split the app into multiple html pages on the server where each page will have it's own app-jsdeps.js and app-opt.js files which means new React-router for each page ?
• Or do we split the app-jsdeps.js and app-opt.js into multiple files so that the download happens concurrently instead of one big chunk ?

Answer 1

You can asynchronusly load jsdeps required per page , i am currently doing this in scalajs-react-components demo app

Async Mixin

Async Mixin Example

app-opt.js file is around 900kb

after gZip it'll be around ~ 350-370kb. Just a to clarify things scala.js core (current version) adds around ~ 150kb -200kb (before gZip for medium to big projects) to output files , in u r case size is huge because spa-tutorial depends on scalajs-react and scalacss (these two libs internally depends on scalaz,shapeless.., ofc they exist to provide you more safety!) - https://github.com/japgolly/scalacss/issues/17 , after this base size even if you add more and more functionality to u r project, size doesn't change much.

that being said, if you enable long term caching you don't need worry about anything that mentioned above. User experience a slight delay on first time visit to your page ,further visits will be instant almost. here is an example using webpack : http://webpack.github.io/docs/long-term-caching.html

btw we must take care of all these for any web project,sclaa.js is no exception ;)

Answer 2

Also, keep in mind that, for a production release, you should typically use minified JS dependencies, and use -jsdeps.min.js instead of -jsdeps.js, as described here. If your JavaScript dependencies are built with a good minifier, it can help quite a bit even without gzip.

And as noted by @invariant, so long as the client is caching the jsdeps, the impact is limited to the first hit on the page, and things go much faster after...