[1]: http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...
[1]: http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...
Let's say your framework size is something wildly unrealistically ludicrous, say 10 MB after gzipping etc. Assuming daily deploys, with the average US internet connection being 18 Mbps, that's a wait time of about 4.4 seconds per user per day: Even in this nuclear unthinkable scenario of 10MB, the result to the end user is a 4 second wait time if they refresh right after your deploy, and then it's instant due to caching. This is a noticeable, minor annoyance to the user but nothing to lose sleep over. Your app can still be successful, as GMail has proven, which would probably take 10s to start even on a quantum computer.
Now let's bring those numbers down to the real world. We're choosing between a framework that's 20kb and one that's 50kb. 8 and 22 ms total user wait time per deploy respectively. Even on mobile, users will never know the difference.
Back to Scala.js. I love Scala, and I want to work with and hire people who love Scala. Using this language is of critical importance to my business. Why should I consider giving it up to save 14ms/user/day?
The framework is basically the entire Scala runtime. You need a list - you execute that code. Not a biggy
But if you're developing a larger front-end application, that tax is dwarfed by the size of your actual application.
Also, Scala.js can be and is used for other JS-based environemnts, which are less size-constrained, such as Node.js, electron, etc.