Announcing Scala.js 0.6.8

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).

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

You could take a look at the stuff that li haoyi does: https://github.com/lihaoyi/autowire (because you mentioned rpc, but also his other stuff. His output is amazing).

I built Boilerplay for that exact purpose - 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.

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

That's what I've used for one of my projects and it's worked out pretty well!

Yes, it would be lovely if one could:

    import 'MyModule' from 'MyModule.scala.js'

easily from Webpack, etc.

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.

We are thinking about that: https://github.com/scala-js/scala-js/issues/2175

But, as other comments note, this is a non-trivial problem.

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.

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.