
Announcing Scala.js 0.6.8 - based2
http://www.scala-js.org/news/2016/03/18/announcing-scalajs-0.6.8/
======
gedy
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
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
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
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
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?

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

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

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

~~~
gedy
Since webpack does dead code elimination as well, wondering if that all needs
to be a problem solved in Scala.js?

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

------
networked
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?

------
virtualwhys
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-198150...](https://github.com/scala/scala/pull/5003#issuecomment-198150391)

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

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

