Now, having seen the talk at Scala days here are a few notes/thoughts:
This is currently the result of 4 months worth of work, and Sébastien Doeraene, the author of the slides and the code there-in, is going to be working on it at EPFL for the next 4 years or so for his doctorate.
When the slide showing that it is 16MB came up everyone laughed and the author acknowledged how large a number this is. It is the result of having to bring in the entire the Scala standard lib. He is planning to work on ways of cutting this number down.
At the end of talk Martin Odersky commented from the audience that this is an attempt by the EPFL at making Scala useable for large webapp development. If it proves successful more resources will put towards supporting it.
"How to scale to Rich Internet Applications?"
Good question. They didn't answer it. Is the Scala code going to be much more compact? And what problems scaling JS to rich applications were they thinking of, exactly? They don't say.
The slides shown there are, well, slides. They are meant to support a talk, and that talk addressed your comments, at least partly. It is also worth noting that it was Scala Days, and as such I took it for (almost) granted that the audience is converted to Scala.
We scale to Rich Internet Applications by using the language Scala, which is a scalable language. I won't try and make a whole point here. Some people have moved from Java to Scala for that very reason.
And, yes, the 16 MB are for the standard library. But minifying was only the first step towards reducing that size. I have at least 4 ideas, which I believe will each divide that size by ~2. That should bring it down under 1 MB.
Seeing the presentation, I'm thinking more of using it with something like node-webkit though. Didn't LightTable use clojure-script or something? But then, why don't just use one of JVM's GUI framework?
1.) increase difficulty debugging (compiled js -> scala)
2.) decrease productivity, see #1
Again, super cool. The author is waaay smarter than I for implementing this, but... The real world.
Quick comment from the author: #1 has already been addressed by emitting Source Maps. With a supporting browser, you can debug your Scala.js application easily. You get positions in the original source code, breakpoints in the original source code, stack traces in the original source code, etc.
Similarly, for someone who is learning scala and doesn't have/want java+IDE experience, this could lead to learning scala as a language with much less overhead and/or while learning a more useful combination of debugger and editor.
For Android development, install Scala runtime into rooted phone, so you don't need to "minify" your code (faster roundtrip). For Scala.js, maybe use Chrome Extension?
For production, ProGuard (removes unused code in Scala) and Closure Compiler (optimizes JS).
How much of this is (b)?
That said- it's not a superior language, just a different paradigm. With Scala you get very strong typing, functional constructs (so incredibly powerful), matching, options, very clean closure syntax, etc.. You'll eventually fall in-love with _, too.
I haven't used scala.js yet, but here are some downsides to Scala proper:
* slow the compile
* tooling isn't great (this true of anything jvm to some degree though)
Well, you have plenty of very decent tools to inspect a running JVM state, and that's priceless. Eclipse is alright if you manage to set it up once with the tools you need and don't fiddle with the setup afterwards. Although slow, it packs a lot more features out of the box than Visual Studio. The debugger is pretty good too (including remote debugging).
If you compare it to state-of-the-art tooling for more fringe languages like Python or Haskell, it's lightyears better, really.
If you compare Scala.js to similar languages (CoffeeScript, TypeScript, ClojureScript to name a few), it definitely helps to have the same language both on server and client, especially if logic must be replicated on both sides. So in that sense, there is some (a) too.
But that is only my opinion. Any developer or team can make up her own mind on the matter.