13 ms·

Scala.JS 0.6.17 released

89 points by scalatohaskell 9y ago

partycoder 9y ago
Sad that Scala.js will not use WebAssembly, since WebAssembly doesn't provide GC.
- sjrd 9y ago
  WebAssembly will most likely eventually provide a GC, at which point we'll do what we can to support compiling to wasm. See also: https://github.com/WebAssembly/gc/pull/1#discussion_r110997852 https://github.com/WebAssembly/gc/pull/1#discussion_r1109978...
  - themihai 9y ago
    They don't seem be on Chrome roadmap. We'll all grow full beards by the time DOM and GC become available. https://wasmdash.appspot.com https://wasmdash.appspot.com
    - sjrd 9y ago
      GC support can hardly be on Chrome's roadmap when the design of the spec has hardly anything more than "we want to have it, and here are some vague goals". So yes, we'll grow beards, but it will happen. Remember though that wasm as whole happened in only a few years!
- user1241320 9y ago
  My two cents: to me WebAssembly seems like something Scala Native might address, more than Scala.js. Or even better, both project can sort of blend for this purpose as on one hand (SN) addresses LLVM compilation and the other (SJS) is perfect JS interop (not so sure how WebAssembly does that).
  - sjrd 9y ago
    > not so sure how WebAssembly does that 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 :)
    - user1241320 9y ago
      I, sort of, know the limitations WebAssembly has right now when it comes to JS interop (such as only being able to use functions with numbers as parameters!) but my guess is this is temporary. It'd be curious to see experiments doing something Scala Native -> Emscripten -> JS-land. Regardless, thanks so much for the work you're doing with Scala.ks (Scala is still my main language and I'm working on removing JS from my toolbox soon). https://youtu.be/HktWin_LPf4?t=22m31s https://youtu.be/HktWin_LPf4?t=22m31s
    - mafribe 9y ago
      Scala.js could write their own GC to hook into WASM as a library, and ship it with Scala.js until WASM has its own GC. Indeed, such competition could spur on the the WASM team(s) to accelerate work on GC.
      - sjrd 9y ago
        That would not solve that essential part: > it needs to integrate with JS objects, which means with the JS GC Otherwise we would have done it already.
        mafribe 9y ago
        Could you not have a radical separation between data to be collected by Scala.js GC, and data GCed by Javascript? Data that crosses the boundary is deep-copied so as to avoid interference between both collectors? Not good for performance, but possible in principle, and a stop-gap measure until the WASM GC lands.
- Matthias247 9y ago
  What do you exactly expect from targetting WASM instead of JS? Higher performance? Smaller bundles and faster load times? Better interoperability?
  - sjrd 9y ago
    Better interoperability, definitely not. Scala.js already has the best interoperability out there, excluding languages with the same run-time semantics as JS (such as TypeScript). In fact, it is the lack of good interoperability in wasm that currently prevents us from compiling Scala.js to that target. 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.
    - paulddraper 9y ago
      Yeah, but Scala started out on a JIT runtime. I'm skeptical a non-JIT would really be that much better.
      - sjrd 9y ago
        As I said in the parent, in the case of Scala.js, I believe we lose more performance because of the loss of static types than we would if we lost the JIT. Performance measurements in Scala Native, which has no JIT and is still quite young (so not very optimized yet), suggest than we can easily be within 2x of the JVM for Scala code, even without JIT.
jaimex2 9y ago
Does anyone use this?
- wbillingsley 9y ago
  Yes, for quite a few projects. 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/ http://www.wbillingsley.com/veautiful/
- continuational 9y ago
  We use Scala.JS in production, and so far we haven't had a single issue with it. Cross-JS/JVM projects have hairy .sbt files though.
- slovic 9y ago
  yes, I've one big project in it. Currently working with: ui -> scalatags, serialisation -> upickle.
- lutzh 9y ago
  Well, for one, the world's 3rd biggest software company, SAP. See http://event.scaladays.org/scaladays-cph-2017#!#schedulePopupExtras-8125 http://event.scaladays.org/scaladays-cph-2017#!#schedulePopu... - quote: "The application development stack we are building embraces Scala all over the place – including the development of user interfaces for which Scala.js is utilized to provide a type-safe interface to SAP's own JavaScript UI library SAP UI5."
- virtualwhys 9y ago
  Sure, replacing a legacy Coffeescript + jQuery app with pure Scala.js. Implementing core functionality of various jQuery plugins (Datatables, Validation, FancyBox, Bootstrap Date/Time pickers, etc.) in Scala.js. Payload is less than 50% of previous version's app bundle. You can of course pull in client-side libs as you like, but for this project it's been really nice to strip out the bloat. 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 ;-)
sjrd 9y ago
Scala.js author here. Ask me anything ;)
- atemerev 9y ago
  Do your know that you have done the impossible and single-handedly revived Scala? It was slowly dying two years ago, with all that Dotty uncertainty and Typesafe->Lightbend transition. 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. :)
  - sjrd 9y ago
    Thank you for your kind words :) It's always nice to see that one's work is appreciated!
  - adriaanm 9y ago
    > Typesafe->Lightbend transition 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,...
    - atemerev 9y ago
      Yes, it all went in a good way. However, this was a scary time, observing Typesafe (now Lightbend) slowly transforming into a garden variety enterprise Java consulting shop, and watching more and more core platforms like Akka being adapted back to Java... Things look better now. :)
sraquo 9y ago
Scala.js has been an amazing tool for my personal projects. I literally hit euphoria sometimes writing stuff in it. I am yet to truly grasp the benefits of full stack Scala (shared models, Autowire, etc.) but even for purely front-end development it's great, it beats Typescript and Flow out of the water in features, soundness and stability. 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.
- sjrd 9y ago
  You are mostly accurate wrt. the "financial" situation of Scala.js. Except that the Scala Center has an explicit Recommendation to "ensure the continuity of Scala.js" [1]. At least that means that, should I (the Ph.D. student doing Scala.js right now) stop working on it, the Scala Center has a mission to ensure someone keeps working on it. As with all Scala Center Recommendations, this is not a guarantee. But given the popularity of Scala.js within the Scala eco-system, I am confident that solutions will be found! Read more about the Scala Center and how it works at [2] [1] https://github.com/scalacenter/advisoryboard/blob/master/minutes/001-2016-q2.md#proposal-scp-005-ensurance-of-continuity-of-scalajs-project https://github.com/scalacenter/advisoryboard/blob/master/min... [2] https://scala.epfl.ch/ https://scala.epfl.ch/
  - sraquo 9y ago
    Thanks! You know, if it comes to that, Scala.js community is a passionate bunch, we could probably crowdfund it :)
  - lomnakkus 9y ago
    > the Scala Center has a mission to ensure someone keeps working on it. 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. :)
galfarragem 9y ago
Scala is still growing popular: https://insights.stackoverflow.com/trends?tags=scala%2Cgo%2Ctypescript%2Crust https://insights.stackoverflow.com/trends?tags=scala%2Cgo%2C...
- brianwawok 9y ago
  Looks like it has peaked to me..
- todd8 9y ago
  This looks pretty good, but Google trends doesn't show any growth for functional languages over the years :( https://trends.google.com/trends/explore?q=scala%20programming,haskell%20programming,ocaml%20programming,go%20programming,python%20programming https://trends.google.com/trends/explore?q=scala%20programmi...

partycoder 9y ago

Sad that Scala.js will not use WebAssembly, since WebAssembly doesn't provide GC.

sjrd 9y ago
WebAssembly will most likely eventually provide a GC, at which point we'll do what we can to support compiling to wasm. See also: https://github.com/WebAssembly/gc/pull/1#discussion_r110997852 https://github.com/WebAssembly/gc/pull/1#discussion_r1109978...
- themihai 9y ago
  They don't seem be on Chrome roadmap. We'll all grow full beards by the time DOM and GC become available. https://wasmdash.appspot.com https://wasmdash.appspot.com
  - sjrd 9y ago
    GC support can hardly be on Chrome's roadmap when the design of the spec has hardly anything more than "we want to have it, and here are some vague goals". So yes, we'll grow beards, but it will happen. Remember though that wasm as whole happened in only a few years!
user1241320 9y ago
My two cents: to me WebAssembly seems like something Scala Native might address, more than Scala.js. Or even better, both project can sort of blend for this purpose as on one hand (SN) addresses LLVM compilation and the other (SJS) is perfect JS interop (not so sure how WebAssembly does that).
- sjrd 9y ago
  > not so sure how WebAssembly does that 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 :)
  - user1241320 9y ago
    I, sort of, know the limitations WebAssembly has right now when it comes to JS interop (such as only being able to use functions with numbers as parameters!) but my guess is this is temporary. It'd be curious to see experiments doing something Scala Native -> Emscripten -> JS-land. Regardless, thanks so much for the work you're doing with Scala.ks (Scala is still my main language and I'm working on removing JS from my toolbox soon). https://youtu.be/HktWin_LPf4?t=22m31s https://youtu.be/HktWin_LPf4?t=22m31s
  - mafribe 9y ago
    Scala.js could write their own GC to hook into WASM as a library, and ship it with Scala.js until WASM has its own GC. Indeed, such competition could spur on the the WASM team(s) to accelerate work on GC.
    - sjrd 9y ago
      That would not solve that essential part: > it needs to integrate with JS objects, which means with the JS GC Otherwise we would have done it already.
      - mafribe 9y ago
        Could you not have a radical separation between data to be collected by Scala.js GC, and data GCed by Javascript? Data that crosses the boundary is deep-copied so as to avoid interference between both collectors? Not good for performance, but possible in principle, and a stop-gap measure until the WASM GC lands.
Matthias247 9y ago
What do you exactly expect from targetting WASM instead of JS? Higher performance? Smaller bundles and faster load times? Better interoperability?
- sjrd 9y ago
  Better interoperability, definitely not. Scala.js already has the best interoperability out there, excluding languages with the same run-time semantics as JS (such as TypeScript). In fact, it is the lack of good interoperability in wasm that currently prevents us from compiling Scala.js to that target. 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.
  - paulddraper 9y ago
    Yeah, but Scala started out on a JIT runtime. I'm skeptical a non-JIT would really be that much better.
    - sjrd 9y ago
      As I said in the parent, in the case of Scala.js, I believe we lose more performance because of the loss of static types than we would if we lost the JIT. Performance measurements in Scala Native, which has no JIT and is still quite young (so not very optimized yet), suggest than we can easily be within 2x of the JVM for Scala code, even without JIT.

jaimex2 9y ago

Does anyone use this?

wbillingsley 9y ago
Yes, for quite a few projects. 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/ http://www.wbillingsley.com/veautiful/
continuational 9y ago
We use Scala.JS in production, and so far we haven't had a single issue with it. Cross-JS/JVM projects have hairy .sbt files though.
slovic 9y ago
yes, I've one big project in it. Currently working with: ui -> scalatags, serialisation -> upickle.
lutzh 9y ago
Well, for one, the world's 3rd biggest software company, SAP. See http://event.scaladays.org/scaladays-cph-2017#!#schedulePopupExtras-8125 http://event.scaladays.org/scaladays-cph-2017#!#schedulePopu... - quote: "The application development stack we are building embraces Scala all over the place – including the development of user interfaces for which Scala.js is utilized to provide a type-safe interface to SAP's own JavaScript UI library SAP UI5."
virtualwhys 9y ago
Sure, replacing a legacy Coffeescript + jQuery app with pure Scala.js. Implementing core functionality of various jQuery plugins (Datatables, Validation, FancyBox, Bootstrap Date/Time pickers, etc.) in Scala.js. Payload is less than 50% of previous version's app bundle. You can of course pull in client-side libs as you like, but for this project it's been really nice to strip out the bloat. 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 ;-)

sjrd 9y ago

Scala.js author here. Ask me anything ;)

atemerev 9y ago
Do your know that you have done the impossible and single-handedly revived Scala? It was slowly dying two years ago, with all that Dotty uncertainty and Typesafe->Lightbend transition. 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. :)
- sjrd 9y ago
  Thank you for your kind words :) It's always nice to see that one's work is appreciated!
- adriaanm 9y ago
  > Typesafe->Lightbend transition 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,...
  - atemerev 9y ago
    Yes, it all went in a good way. However, this was a scary time, observing Typesafe (now Lightbend) slowly transforming into a garden variety enterprise Java consulting shop, and watching more and more core platforms like Akka being adapted back to Java... Things look better now. :)

sraquo 9y ago

Scala.js has been an amazing tool for my personal projects. I literally hit euphoria sometimes writing stuff in it. I am yet to truly grasp the benefits of full stack Scala (shared models, Autowire, etc.) but even for purely front-end development it's great, it beats Typescript and Flow out of the water in features, soundness and stability. 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.

sjrd 9y ago
You are mostly accurate wrt. the "financial" situation of Scala.js. Except that the Scala Center has an explicit Recommendation to "ensure the continuity of Scala.js" [1]. At least that means that, should I (the Ph.D. student doing Scala.js right now) stop working on it, the Scala Center has a mission to ensure someone keeps working on it. As with all Scala Center Recommendations, this is not a guarantee. But given the popularity of Scala.js within the Scala eco-system, I am confident that solutions will be found! Read more about the Scala Center and how it works at [2] [1] https://github.com/scalacenter/advisoryboard/blob/master/minutes/001-2016-q2.md#proposal-scp-005-ensurance-of-continuity-of-scalajs-project https://github.com/scalacenter/advisoryboard/blob/master/min... [2] https://scala.epfl.ch/ https://scala.epfl.ch/
- sraquo 9y ago
  Thanks! You know, if it comes to that, Scala.js community is a passionate bunch, we could probably crowdfund it :)
- lomnakkus 9y ago
  > the Scala Center has a mission to ensure someone keeps working on it. 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. :)

galfarragem 9y ago

Scala is still growing popular: https://insights.stackoverflow.com/trends?tags=scala%2Cgo%2Ctypescript%2Crust https://insights.stackoverflow.com/trends?tags=scala%2Cgo%2C...

brianwawok 9y ago
Looks like it has peaked to me..
todd8 9y ago
This looks pretty good, but Google trends doesn't show any growth for functional languages over the years :( https://trends.google.com/trends/explore?q=scala%20programming,haskell%20programming,ocaml%20programming,go%20programming,python%20programming https://trends.google.com/trends/explore?q=scala%20programmi...