Cross-Platform Language Design [pdf] | Hacker News Reader

Cross-Platform Language Design [pdf]

lampwww.epfl.ch

94 pointslihaoyi16 comments

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/FromfirstprinciplesWhyIbetonScal...

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.

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?

Download time is not the only metric you should watch out for, there's also execution time.

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

I needed to write a little web utility a few months back and was pleasantly surprised at just how easy Scala.js makes it (as a Scala programmer): write some code, put a couple of lines in config and you're basically done. I wrote a blog post about my deployment experience at http://m50d.github.io/2018/11/29/deploying-scalajs-with-netl... and honestly felt like I was having to pad it out to article length.

Hi, author here. Feel free to ask any question :-)

Nice work, congratulations!

What do you think will be the long-term story for Scala.js, with WebAssembly becoming mainstream, and current WASM shortcommings (e.g. GC and concurrency) out of the way? Do you expect Scala.js folding back into Scala?

Other question, does Scala's moving towards DOT-based foundations (e.g. dotty) affect Scala.js?

Wasm will not influence Scala.js' semantics. Scala.js "folding back into Scala" would be a regression as far as development for JavaScript platforms goes. Scala without Scala.js means a Scala that cannot interact with its environment, which has JavaScript APIs (e.g., the DOM). I am looking forward to Wasm with GC features as a different target for Scala.js (not Scala), with the same semantics, but different trade-offs in terms of performance and compactness.

Scala moving to DOT-based foundations is orthogonal to Scala.js. We'll have to rewrite parts of the compiler to adapt to dotty's internal, of course (and that is being done [1]), but at the language level, it is entirely orthogonal. Of course, we'll benefit from a better union type, which is very important for Scala.js, but it's not really a language interaction.

[1] https://github.com/lampepfl/dotty/pull/5143

For those that don't know- scalatags is an amazing html-ish library that allows you to write html once and render both from server and from client. SSR and SPA in one for you cool kids out there.

Not to mention no more misspellings of attributes with strong typed html

I hope lightbend will spend some marketing dollars when it reaches 1.0!

Doraene doesn't work for Lightbend though.

No, but I do work for the Scala Center (https://scala.epfl.ch/).

Then lightbend should buy Scala.js and scalatags and add a virtual Dom based reactive renderer. (currently string and Dom are available)

There are several Scala libraries providing this (the most popular probably being https://github.com/japgolly/scalajs-react). Have you tried one of them?

I want something very simple. Scala.rx + scalatags.

Reply on news.ycombinator.com