
Cross-Platform Language Design [pdf] - lihaoyi
http://lampwww.epfl.ch/~doeraene/thesis/doeraene-thesis-2018-cross-platform-language-design.pdf
======
mwcampbell
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...](http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScalajs.html)

~~~
lopatin
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
Download time is not the only metric you should watch out for, there's also
execution time.

~~~
vtesucks
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

------
lmm
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...](http://m50d.github.io/2018/11/29/deploying-scalajs-with-netlify) and
honestly felt like I was having to pad it out to article length.

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

~~~
YorkshireSeason
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?

~~~
sjrd
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](https://github.com/lampepfl/dotty/pull/5143)

------
vtesucks
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

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

~~~
kaidax
Doraene doesn't work for Lightbend though.

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

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

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

