
Scala.js 1.0.0-RC1 - sjrd
https://www.scala-js.org/news/2019/11/26/announcing-scalajs-1.0.0-RC1/
======
threeseed
Would highly recommend pairing this with Slinky (React for Scala.js).

[https://slinky.dev](https://slinky.dev)

~~~
gedy
I'm disappointed that the (formerly?) built-in Scala XML handling could not be
used for JSX vs these:

Slinky:

    
    
       div(
          h3("TODO"),
          TodoList(items = state.items),
          form(onSubmit := (handleSubmit(_)))(
            input(
              onChange := (handleChange(_)),
              value := state.text
            ),
            button(s"Add #${state.items.size + 1}")
          )
        )
    

scalajs-react:

    
    
        <.div(
          NoArgs(),
          Hello("John"),
          Hello("Jane"))

~~~
sjrd
If you're into JSX, then probably Bindings.scala is a better fit for you:

[https://github.com/ThoughtWorksInc/Binding.scala#step-3-crea...](https://github.com/ThoughtWorksInc/Binding.scala#step-3-create-
a-dom-method-that-contains-data-binding-expressions)

~~~
gedy
Looks awesome, thank you!

------
utkarshkukreti
Anyone know what's the minimum size of the compiled JS now? Is there any way
Scala.js can produce code as compact as BuckleScript/ReasonML in the future?

I like Scala's syntax but the last time I tried Scala.js, the output was
several hundred kb for something slightly more than a Hello World -- it used
some List and Seq functions. I'd bet the comparable ReasonML output would
likely be in tens of kb (including List and Array functions from Belt).

~~~
sjrd
The bare minimum for a hello world is 6 KB (before gzip). But of course as
soon as you start using Scala collections, it's getting bigger. The minimum
for a _realistic_ application is 90 KB (before gzip).

That's less than your typical JavaScript framework, so for any realistic
application it shouldn't be a concern.

~~~
googleisevil6
For refernce- Jquery unzipped is similar size- 87K and while it adds much more
functionality, Scala collections easily trump jquery's in usability and power.

SJRD, Would you also add a bit more info about how this size increases? I
haven't cared much but it seems from your comments that the slope should be
much less once you reach 90kb.

~~~
fnordsensei
ClojureScript ends up somewhere around the same size. Maybe it's some magic
number that a full-featured environment converges to.

Since Scala.js (like CLJS) is backed by Google Closure Compiler, I bet you'll
also reach for the Closure Library for a lot of stuff where one might reach
for JQuery or equivalent otherwise. The stuff in there is of course optimized
for Closure Compiler, and slims down quite well.

~~~
sjrd
There is a significant difference between CLJS and Scala.js regarding their
use of GCC (Google Closure Compiler).

In ClojureScript, GCC is a user-visible feature of the toolchain, so users are
encouraged to use GCC-compatible libraries and the Closure Library in
particular.

In Scala.js, GCC is really an implementation detail of the toolchain, and its
constraints are completely abstracted away from the user. This does not really
encourage using GCC-oriented libraries like the Closure Library.

The two approaches each have pros and cons:

* CLJS' approach allows tree shaking across the CLJS code and the GCC-compatible libraries that are used. However, it makes it more difficult to use libraries that do not comply with GCC's Advanced Optimizations requirements, as one needs to declare the proper `externs` files.

* Scala.js' approach means that you can use any JavaScript library out of the box, whether or not it was designed for GCC, and without having to declare any `externs` file. However, it means that GCC's tree shaking will not be applied across the Scala.js code and the JS libraries. It only applies to Scala.js' own code.

~~~
fnordsensei
I think the externs file maneuver might be outdated.

Admittedly, I'm using shadow-cljs as my go-to compiler (so I'm not sure what
the state of vanilla is), but all I do is yarn add <package>, and then require
it in the file where I want to use it, and interact with it as if it were any
other library.

Though it is true of shadow-cljs as well that it doesn't try to tree-shake
external (non-CLJS/Closure) libs by default, though it will do it for project
code and Clojure libraries.

------
gedy
I can't speak for everyone, but while I loved programming in Scala, I can't
stand sbt[0] as a build tool. If I could use Scala.js without all this (e.g.
Webpack or Rollup) could see myself using.

[0] [https://www.scala-sbt.org](https://www.scala-sbt.org)

~~~
nafg
Check out Seed -
[https://github.com/tindzk/seed](https://github.com/tindzk/seed)

------
The_rationalist
Can this call js libraries and the DOM trivially like typescript? Or does it
leverage ffi?

~~~
sjrd
It's exactly like TypeScript. You write type definitions or you find them
online, like in TypeScript, then you can call any JavaScript API using the
relevant types.

Full relevant docs at [https://www.scala-
js.org/doc/interoperability/](https://www.scala-js.org/doc/interoperability/)

~~~
manx
Many TypeScript type definitions are also automatically converted to ScalaJS:
[https://github.com/oyvindberg/ScalablyTyped](https://github.com/oyvindberg/ScalablyTyped)

------
AzzieElbab
Always been curious about workflow of people who use Scala.js. I am a complete
newbie when it comes to frontend. How do you do frontendish interactive
development considering scalac's slowness?

~~~
sjrd
scalac is only slow when it needs to compile an entire project. But the Scala
tooling ecosystem has invested _a lot_ in incremental compilation, which means
that most of the time when you make a change, only 1 or 2 files are
recompiled, which is quite snappy. In turn, the Scala.js linker also performs
its linking and optimizations incrementally, so that in an interactive
development setting, the whole cycle is quite fast.

~~~
AzzieElbab
fine, but what tooling/workflow would one use for the type of development
javascripters are accustomed to? Like make a change and immediately observe
result on the page?

~~~
sjrd
Workbench [1], for example :)

[1]
[https://github.com/lihaoyi/workbench](https://github.com/lihaoyi/workbench)

~~~
ramnivasl
Also, if you use webpack (directly or through scalajs-bundler), the use of
webpack-dev-server makes live loading automatic.

------
googleisevil6
As someone who has dropped Scala on the backend (not doing FUD, just not happy
with the JVM memory reqs)- what keeps me still using scala is Scala.js.

While some argue that there is more readable code with Bloomberg's OCaml.js, I
like Scala.js because of Scala itself, which is

1) Very well designed 2) Lots of "functional" constructs in accompanying
libraries 3) Good typechecking 4) Fun language to use.

and because Scala.js interop with JS is very seamless.

Do check out ScalablyTyped repo on Github, a Scala.js analogue of
DefinitelyTyped.

Being typed- one of the best things I like about Scala is that I can do
something like this (provided by a couple of frameworks- Laminar, Scalatags et
al)

<pre> div( Seq( div( "div 1" ) ), div( "div 2" ), b( "bold stuff", i( "italic
inside bold" ) ) ) </pre>

No more mismatching tags, wrongly spelled tags, unclosed tags. Typechecked
HTML in some sense.

This would also be a good place to mention some alternatives where a
mainstream language can also compile to JS so hopefully people can comment
with their experience:

1) F#- Fable 2) OCaml- Bloomberg's BuckleScript 3) Go- Gopher 4) Haskell-
GHCJS

Other non-mainstream but compile-to-JS languages

1) PureScript 2) ELM 3) Clojure script (child comment)

... and of course... TypeScript! :)

It should be noted that while Scala.js isn't as popular as some of it's
alternatives in "popular" programmer culture, the author is very focussed on
correctness and I don't know of anybody who has ever used Scala.js for a
project but dropped it. (Happy to be corrected)

~~~
bad_user
> _just not happy with the JVM memory reqs_

I'm curious if you did any measurements and what you prefer instead.

The managed heap is very efficient. I have a web server (built in Scala)
configured on my own VPS to run with a 10-100 MB heap. To this you add the
JVM's memory used for managing OS threads, opened sockets, JNI, GC overhead
and I end up with a process using 190 MB (RES), which is reasonable for a
server-side process, because you can actually do a lot in it, Java processes
being able to be fat.

In my experience a well grown Java process will be much more efficient and
predictable in terms of memory used than Node.js, PHP, Ruby, Python, at the
very least.

The only problem I've experienced is the startup time, plus depending on use
case I might prefer native binaries. GraalVM looks promising.

Scala.js is useful on the sever for example if you need to work with
"serverless" tech, e.g. AWS Lambda, for which startup time is important.

~~~
merb
well compared to dotnet core 3 the java memory management is really really
bad. in java memory is not more efficient than in node.js/php/ruby or python
it's worse. what is better is the performance, especially when you have a lot
of stuff on the heap the performance is predictable even with a memory size of
> 16gb where the other languages lack of. GraalVM still misses a lot of stuff
and is slower.

so I think the biggest buck for the bang actual is dotnet (maybe go is as good
as well, but does not really play in the same league). I think once valhalla
hits the tables might change, but even than ReadOnlySpan<T> is way too awesume
than just value types.

~~~
vips7L
>GraalVM still misses a lot of stuff and is slower.

Are there benchmarks for this?

~~~
merb
well he talked about the AOT stuff. which is not on par as dotnet core's aot
approach in 3.0, however default graalvm is quite fast (but still memory
hungry)

