6 ms·

Announcing Scala.js 0.6.8

70 points by based2 11y ago

virtualwhys 11y ago
I wonder if the 10-20% reduction in jar size[1] in current Scala 2.12 milestone will carry over to Scala.js? Or maybe Google Closure Compiler is already stripping out loads of anonymous classes in pre-2.12 Scala.js via aggressive DCE. Would obviously be nice to get generated js blob as lean as possible since Scala 2.13 and overhauled/streamlined collections is still a ways off (at least 18 months post-2.12 GA if release schedule holds). [1] https://github.com/scala/scala/pull/5003#issuecomment-198150391 https://github.com/scala/scala/pull/5003#issuecomment-198150...
- kodablah 11y ago
  I would guess unlikely. The reduction in JAR size as mentioned there is due to relying on Java 8 now which gives more JVM-native approaches to things Scala was otherwise emulating (e.g. multiple inheritance). Scala.JS works off of an IR and is not related to native JVM constructs or JVM bytecode.
- sjrd 11y ago
  Unlikely, because Scala.js already has the reductions that are brought on the JVM only in 2.12. Scala.js has been emitting tiny wrappers around JS closures for more than 2 years. (and no, that's not because of Closure; it's because of our own compiler and optimizer) The overhaul of collections is, in part, supposed to be more friendly to Scala.js and in particular code size of small applications.
crudbug 11y ago
I think all X => JS programming languages should support webpack loaders with commonJS module system for smooth transitions from one language to another.
- gedy 11y ago
  Yes, it would be lovely if one could: import 'MyModule' from 'MyModule.scala.js' easily from Webpack, etc.
  - crudbug 11y ago
    Agreed!
- easel 11y ago
  It would indeed by lovely, but also a bit of a challenge in this case. Part of how scala.js is able to achieve reasonable javascript size is that it uses very aggressive dead code elimination including google closure compiler. In order to do that, it has to see ALL the code that's actually going to be used. There's nothing preventing that single blob from being exported to webpack. I currently export stuff into a legacy require.js/angular app using globals, so I imagine the same could be accomplished with webpack. The issue will arise when you attempt to include multiple "scala.js webpack" modules. Each one will be compiled as an independent unit and carry it's own subset of the scala standard libraries, etc. For a transitional scenario, that's probably fine, but it does make participation in a fully polyglot webpack-loader or npm ecosystem problematic.
  - dustingetz 11y ago
    A simpler case is a scalajs app depending on commonjs modules, I think this should be possible? One problem is that a commonjs module depends on other commonjs modules, so maybe it becomes all or nothing
  - gedy 11y ago
    Since webpack does dead code elimination as well, wondering if that all needs to be a problem solved in Scala.js?
    - sjrd 11y ago
      Scala.js does a much better dce than Webpack, or any other JavaScript optimizer (including Closure). It does it at the method level (not top-level function/class level), and can also leverage the type system to do a better job at it. So yes, it needs to be solved at the Scala.js level. Scala.js also performs whole-program optimizations of the code, besides "simple" dead cole elimination.
- sjrd 11y ago
  We are thinking about that: https://github.com/scala-js/scala-js/issues/2175 https://github.com/scala-js/scala-js/issues/2175 But, as other comments note, this is a non-trivial problem.
  - crudbug 11y ago
    Exporting ES6 compatible modules. Very promising enhancement. Thanks !
gedy 11y ago
This is a really nice project, and personally is a humorous full-circle: When I first started moving away from Java web apps (where I hated JavaScript), I fell in love with Scala and it's mix of functional and OOP. Features like Futures/Promises, closures, awesome collection library, etc were so refreshing from Java at the time. After a year or so though, I realized JavaScript offered almost the exact same functionality, and had nice libs like underscore.js for collections, etc. :-) I've been basically 100% JS for the past 4 years, but still admire Scala.
- semigroupoid 11y ago
  For me, one of Scala's most important features is its type system, which you aren't able to get in JavaScript (I know about flow and TypeScript, but they don't even come close in terms of features).
  - sscarduzio 11y ago
    I could have stopped reading after seeing your user name :) Personally, Scala types are as powerful as intimidating, nevertheless acceptable for the value they enable for writers of libraries (which I probably never will be).
    - yawaramin 11y ago
      I read somewhere that Edward Kmett described how he writes apps: he first factors out the functionality into powerful, general-purpose libraries, and then just implements his app as a thin wrapper over the libraries. So, it's a matter of your mindset :-)
eranation 11y ago
Anyone doing some interesting Scala front and back projects? I'd love to hear some success (or lessons learned) stories. Is there a good "skeleton" project for a front end Scala.js + back end Scala. I'm especially interested in reusing model objects between front and back, or is the best practice still to just use REST services the "old fashioned" way? (vs a more GWT-like approach that feels a little more like an RPC) I would love to have my next project be all Scala but I wonder what are the benefits beyond just having a single language in the project. Is there a good sbt plugin / template that has a good workflow for continuous development/integration/deployment using Scala+Scala.js?
- easel 11y ago
  There's a list of sites using scala.js on the website that evolves quite regularly. The scalajs-spa-tutorial at https://github.com/ochrons/scalajs-spa-tutorial https://github.com/ochrons/scalajs-spa-tutorial is probably the best place to see a full stack app that you can poke and prod at. It's been through a few iterations by now and represents a number of best practices The biggest benefit is probably having a solid type system that's isomorphic. Large, complex responses and post bodies can be seamlessly passed around with full IDE support and refactoring. Beyond that, it's scala.
- redtuesday 11y ago
  You could take a look at the stuff that li haoyi does: https://github.com/lihaoyi/autowire https://github.com/lihaoyi/autowire (because you mentioned rpc, but also his other stuff. His output is amazing).
- kyle_u 11y ago
  I built Boilerplay for that exact purpose - https://github.com/KyleU/boilerplay https://github.com/KyleU/boilerplay It uses the excellent sbt-scalajs to provide code shared between server and client, and a websocket controller that can receive those shared messages. It's tied to Play, sihouette, and postgres-async.
- ybx 11y ago
  The best skeleton I've found (if anything, it does too much even) is Otto Chrons' SPA tutorial: https://github.com/ochrons/scalajs-spa-tutorial https://github.com/ochrons/scalajs-spa-tutorial That's what I've used for one of my projects and it's worked out pretty well!
networked 11y ago
If you have used two or more of GWT, ClojureScript, Scala.js and Kotlin's and Ceylon's respective JavaScript compiler targets, could you share how working with them compares?
alex_hirner 11y ago
Otto did an amazingly comprehensive webcast on how to dev in scala-js and how it fits into the big picture. https://www.youtube.com/watch?v=NPWDKEQLjpI https://www.youtube.com/watch?v=NPWDKEQLjpI

70 points by based2 11y ago

I wonder if the 10-20% reduction in jar size[1] in current Scala 2.12 milestone will carry over to Scala.js? Or maybe Google Closure Compiler is already stripping out loads of anonymous classes in pre-2.12 Scala.js via aggressive DCE. Would obviously be nice to get generated js blob as lean as possible since Scala 2.13 and overhauled/streamlined collections is still a ways off (at least 18 months post-2.12 GA if release schedule holds). [1] https://github.com/scala/scala/pull/5003#issuecomment-198150391 https://github.com/scala/scala/pull/5003#issuecomment-198150...

kodablah 11y ago
I would guess unlikely. The reduction in JAR size as mentioned there is due to relying on Java 8 now which gives more JVM-native approaches to things Scala was otherwise emulating (e.g. multiple inheritance). Scala.JS works off of an IR and is not related to native JVM constructs or JVM bytecode.
sjrd 11y ago
Unlikely, because Scala.js already has the reductions that are brought on the JVM only in 2.12. Scala.js has been emitting tiny wrappers around JS closures for more than 2 years. (and no, that's not because of Closure; it's because of our own compiler and optimizer) The overhaul of collections is, in part, supposed to be more friendly to Scala.js and in particular code size of small applications.

crudbug 11y ago

I think all X => JS programming languages should support webpack loaders with commonJS module system for smooth transitions from one language to another.

gedy 11y ago
Yes, it would be lovely if one could: import 'MyModule' from 'MyModule.scala.js' easily from Webpack, etc.
- crudbug 11y ago
  Agreed!
easel 11y ago
It would indeed by lovely, but also a bit of a challenge in this case. Part of how scala.js is able to achieve reasonable javascript size is that it uses very aggressive dead code elimination including google closure compiler. In order to do that, it has to see ALL the code that's actually going to be used. There's nothing preventing that single blob from being exported to webpack. I currently export stuff into a legacy require.js/angular app using globals, so I imagine the same could be accomplished with webpack. The issue will arise when you attempt to include multiple "scala.js webpack" modules. Each one will be compiled as an independent unit and carry it's own subset of the scala standard libraries, etc. For a transitional scenario, that's probably fine, but it does make participation in a fully polyglot webpack-loader or npm ecosystem problematic.
- dustingetz 11y ago
  A simpler case is a scalajs app depending on commonjs modules, I think this should be possible? One problem is that a commonjs module depends on other commonjs modules, so maybe it becomes all or nothing
- gedy 11y ago
  Since webpack does dead code elimination as well, wondering if that all needs to be a problem solved in Scala.js?
  - sjrd 11y ago
    Scala.js does a much better dce than Webpack, or any other JavaScript optimizer (including Closure). It does it at the method level (not top-level function/class level), and can also leverage the type system to do a better job at it. So yes, it needs to be solved at the Scala.js level. Scala.js also performs whole-program optimizations of the code, besides "simple" dead cole elimination.
sjrd 11y ago
We are thinking about that: https://github.com/scala-js/scala-js/issues/2175 https://github.com/scala-js/scala-js/issues/2175 But, as other comments note, this is a non-trivial problem.
- crudbug 11y ago
  Exporting ES6 compatible modules. Very promising enhancement. Thanks !

gedy 11y ago

This is a really nice project, and personally is a humorous full-circle: When I first started moving away from Java web apps (where I hated JavaScript), I fell in love with Scala and it's mix of functional and OOP. Features like Futures/Promises, closures, awesome collection library, etc were so refreshing from Java at the time. After a year or so though, I realized JavaScript offered almost the exact same functionality, and had nice libs like underscore.js for collections, etc. :-) I've been basically 100% JS for the past 4 years, but still admire Scala.

semigroupoid 11y ago
For me, one of Scala's most important features is its type system, which you aren't able to get in JavaScript (I know about flow and TypeScript, but they don't even come close in terms of features).
- sscarduzio 11y ago
  I could have stopped reading after seeing your user name :) Personally, Scala types are as powerful as intimidating, nevertheless acceptable for the value they enable for writers of libraries (which I probably never will be).
  - yawaramin 11y ago
    I read somewhere that Edward Kmett described how he writes apps: he first factors out the functionality into powerful, general-purpose libraries, and then just implements his app as a thin wrapper over the libraries. So, it's a matter of your mindset :-)

eranation 11y ago

Anyone doing some interesting Scala front and back projects? I'd love to hear some success (or lessons learned) stories. Is there a good "skeleton" project for a front end Scala.js + back end Scala. I'm especially interested in reusing model objects between front and back, or is the best practice still to just use REST services the "old fashioned" way? (vs a more GWT-like approach that feels a little more like an RPC) I would love to have my next project be all Scala but I wonder what are the benefits beyond just having a single language in the project. Is there a good sbt plugin / template that has a good workflow for continuous development/integration/deployment using Scala+Scala.js?

easel 11y ago
There's a list of sites using scala.js on the website that evolves quite regularly. The scalajs-spa-tutorial at https://github.com/ochrons/scalajs-spa-tutorial https://github.com/ochrons/scalajs-spa-tutorial is probably the best place to see a full stack app that you can poke and prod at. It's been through a few iterations by now and represents a number of best practices The biggest benefit is probably having a solid type system that's isomorphic. Large, complex responses and post bodies can be seamlessly passed around with full IDE support and refactoring. Beyond that, it's scala.
redtuesday 11y ago
You could take a look at the stuff that li haoyi does: https://github.com/lihaoyi/autowire https://github.com/lihaoyi/autowire (because you mentioned rpc, but also his other stuff. His output is amazing).
kyle_u 11y ago
I built Boilerplay for that exact purpose - https://github.com/KyleU/boilerplay https://github.com/KyleU/boilerplay It uses the excellent sbt-scalajs to provide code shared between server and client, and a websocket controller that can receive those shared messages. It's tied to Play, sihouette, and postgres-async.
ybx 11y ago
The best skeleton I've found (if anything, it does too much even) is Otto Chrons' SPA tutorial: https://github.com/ochrons/scalajs-spa-tutorial https://github.com/ochrons/scalajs-spa-tutorial That's what I've used for one of my projects and it's worked out pretty well!

networked 11y ago

If you have used two or more of GWT, ClojureScript, Scala.js and Kotlin's and Ceylon's respective JavaScript compiler targets, could you share how working with them compares?

alex_hirner 11y ago

Otto did an amazingly comprehensive webcast on how to dev in scala-js and how it fits into the big picture. https://www.youtube.com/watch?v=NPWDKEQLjpI https://www.youtube.com/watch?v=NPWDKEQLjpI