I wish I could use it at work since we (Hootsuite) already use Scala heavily on the backend, but I am reluctant in part because Scala.js does not quite have financial support of Lightbend. Or so it seems, it's a bit hard to tell where Lightbend ends and the non-profit Scala Center begins. The latter did pay to get some features implemented but reading their advisory board minutes, I'm not sure if they would have enough funding to pay for the majority of Scala.js development, which if I understand correctly happens for free as part of a PhD right now (note: my information might be wrong/outdated!)
So, if anyone involved with Scala.js is reading this and has better insights on the situation, it would be nice to know.
But I will keep using it regardless. It's marvellous.
[1] https://github.com/scalacenter/advisoryboard/blob/master/min... [2] https://scala.epfl.ch/
Heh, I hope it's you! :)
Seriously, scala.js has been amazing for us! Thank you for all that hard work!
EDIT: Of course you might still be beaten out by scala.native -> WebAssembly -> Browser... nah, not really. :)
Were you at ScalaDays 2017 CPH? I don't think I saw you there, but you deserve a round of applause, you Magnificent Bastard, you!
As the Scala team lead at Lightbend, I'd love to have a few members of my team focus on scala.js and scala-native. We do financially support their development (most recently, as part of our funding of the Scala Center).
As a business, it's a bit of a chicken-and-egg problem: our customers usually indicate they are hesitant to switch from JS for their frontend work. It would be great to have more customers provide feedback like yours (via our customer surveys)!
Having Scala's type system on both client and server is pretty surreal, not to mention full IDE support -- the entire world of javascript just appears as you type ;-)
Also, can scala.js be used for progressive enhancement on static sites, or is it limited to single page apps due to the need to map scala semantics to js?
If you know Scala, you can mostly forget about Javascript and just code everything in Scala both on server and client side, and everything just works magically (using the same data types is PURE PINK UNICORN AND RAINBOW BLISS). If you don't know Scala, your mileage may vary, but I'd learn a bit of Scala just to experience that.
For a number of them I used scala-js-react, though very recently (as of about two weeks ago) I've been playing around with my own (smaller, less opinionated) virtual dom library. http://www.wbillingsley.com/veautiful/
It's a whole different world than anything else in frontend. The libraries from scala are immense.
Then you came and showed us that Scala can be productively used beyond JVM. A new hope appeared, Scala-native was inspired by your example, and Dotty was upgraded from a purely academic exercise to a viable pragmatic way to Scala 3. The attitude was "if Scala.js guys did it, so can we".
So thank you, from me and all Scala hackers out there. Martin owes you a beer. :)
The renaming never affected the staffing of the Scala team at Lightbend -- we've been doing about 2/3 of core Scala development (major thank you to the community for the other third!) since 2.10 (when I went from post-doc in Martin's lab to the Scala team lead position).
In my opinion, it was a good thing that feature development slowed down in Scala 2.x (while Martin pushed the research frontier forward in Dotty), so we could focus on (in no particular order) compiler performance, a new back-end and optimizer, Java 8 support, modularization,...
@ScalaJSDefined
trait Person extends js.Object {
var name: String
var age: Int
}
type Persons = js.Array[Person]
From what I've seen so far there hasn't been much in the way of removals. Ideally the compiler and standard library would be as small as possible in order to help Scala.js streamline generated application binaries.
See also: https://github.com/WebAssembly/gc/pull/1#discussion_r1109978...
Basically: badly. That's the number one reason we're not trying to compile Scala.js to wasm at the moment. For wasm to get the level of JS interop that Scala.js has, it needs to integrate with JS objects, which means with the JS GC, which means basically have a GC of its own. Hence we're waiting for the wasm GC spec to take life :)
We could hope for smaller bundles and faster load times, yes. But mostly we should be able to get faster "cruising" execution. Scala.js being statically typed, there is a lot of static guarantees that we lose when compiling to JS. JS engines are very good and can "recover" a lot of it through JIT'ing, but it's still 3x slower than Scala/JVM on average (after warmup of both), so clearly we lose something non-negligible. By compiling to wasm, we would lose the JIT, but keep the static types. It is unclear how fast we would manage to be, but I would hope we can get within 2x of the JVM instead of 3x-ish.
There is a lot of misconception on the Internet that "wasm makes everything faster". For example, a lot of people want to "compile JS down to wasm" to make it faster. That's bullshit, because your language does not have static types to begin with, so you lose the JIT and gain nothing in exchange, which means you'll run much slower. But if you compile a statically typed language down to wasm, you should be able to gain some significant speed.
https://insights.stackoverflow.com/trends?tags=scala%2Cgo%2C...
https://trends.google.com/trends/explore?q=scala%20programmi...