3 ms·

I find compilation of statically typed languages to JS, as in Scala.js, worthwhile in principle, for the reasons that Haoyi argued so well in a blog post a whil

I find compilation of statically typed languages to JS, as in Scala.js, worthwhile in principle, for the reasons that Haoyi argued so well in a blog post a while back [1]. But there's one major reason I would be reluctant to use Scala.js: runtime footprint. 45 KB gzipped (the number given on scala-js.org) is pretty heavy. Is that an inevitable trade-off for the power of Scala, or is there still more work that can be done to bring that down? [1]: http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScalajs.html http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...

sjrd 8y ago
It's always important to put things into context. If you're developing a hello world or a few animations for your mostly static web site, the initial "tax" of Scala.js will always be too heavy. It's not so much the power of Scala as a language, but rather its collections library. 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.
lopatin 8y ago
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?
- Scarbutt 8y ago
  Download time is not the only metric you should watch out for, there's also execution time.
  - vtesucks 8y ago
    You don't execute all the paths all the time. The framework is basically the entire Scala runtime. You need a list - you execute that code. Not a biggy

sjrd 8y ago

It's always important to put things into context. If you're developing a hello world or a few animations for your mostly static web site, the initial "tax" of Scala.js will always be too heavy. It's not so much the power of Scala as a language, but rather its collections library. 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.

lopatin 8y ago

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?

Scarbutt 8y ago
Download time is not the only metric you should watch out for, there's also execution time.
- vtesucks 8y ago
  You don't execute all the paths all the time. The framework is basically the entire Scala runtime. You need a list - you execute that code. Not a biggy