So I seem to be in the minority on this, and I'm interested in responses about why I'm wrong, but I believe that for most projects the weight in KB your framewo

So I seem to be in the minority on this, and I'm interested in responses about why I'm wrong, but I believe that for most projects the weight in KB your framework/runtime doesn't matter _at all_ when compared to other concerns such as which language to use in your company's front-end stack. 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?