
From first principles: Why I bet on Scala.js - lihaoyi
http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScalajs.html
======
virtualwhys
Article is a total tour de force.

The OP has contributed so much to the Scala community; somehow he's a Python +
Coffeescript developer by day, and an absurdly prolific Scala library author
in the evenings.

As for Scala.js, representing browser interactions in types is such a relief,
and to have the entire Scala language available is almost too good to be true:
client-server interop is _seamless_.

Really the only negative for me is the Scala collections library. Of the
@100KB Hello World[1] generated blob half of that is Scala collections.
There's a small initial "tax" to pay basically, and thereafter size increase
is on par with normal javascript.

[1] not totally true, vanilla Hello World is more like 40KB, but once you
define a Scala collection then generated blob doubles in size.

------
hongboz
For people who want to do typed functional programming on JS platform, there
is another candidate: BuckleScript for OCaml:
[https://bloomberg.github.io/bucklescript/js-
demo/](https://bloomberg.github.io/bucklescript/js-demo/)

The compiler is compiled into JS and native code.

It generates highly readable JS code and easier FFI.

It compiles super fast (generally 10~100 faster than Scala) and generates
optimized code.

~~~
jackmott
and Fable for F#
[https://github.com/fsprojects/Fable](https://github.com/fsprojects/Fable)

~~~
Nelkins
And you can use it with React Native![1]

[1] [http://www.navision-blog.de/blog/2016/08/06/fable-react-
nati...](http://www.navision-blog.de/blog/2016/08/06/fable-react-native/)

------
lihaoyi
I wrote this; ask me anything

~~~
apo
Amazing work - thanks for putting it out there.

In your live coding presentation, you mentioned that the output from compiling
scala to js is several files.

I'm interested in generating one file that exposed JavaScript functions that
can be easily called from a js runtime.

In other words, I'd like to write a JavaScript library in Scala - not a full-
blown application.

What are some good resources showing how to do this?

~~~
lihaoyi
The live coding presentation is two years out of date; Scala.js now compiles
to a single JS blob

Everything function marked with @JSExport will be exposed to Javascript.
There's no concrete difference between an application with one `@JSExport def
main` method that you call to initialize it, and a library with multiple
`@JSExport`ed methods. It all works the same way: the `@JSExport`ed functions
are exposed, and people can call them.

This repo shows how to make a NPM library using Scala.js

\- [https://github.com/rockymadden/scala-
node/](https://github.com/rockymadden/scala-node/)

If you want to learn how to use `@JSExport` properly, the [core
documentation]([http://www.scala-js.org/tutorial/basic/](http://www.scala-
js.org/tutorial/basic/)) and [Hands-on
Scala.js]([http://www.lihaoyi.com/hands-on-scala-
js/](http://www.lihaoyi.com/hands-on-scala-js/)) are great.

------
weego
I've backed the current iteration of my career on Scala and like the idea and
some of the practicalities of Scalajs but it is destined to be limited to fun
projects. The unavoidable problem is by committing to Scalajs you are
accepting that you can no longer go out and get one of any number of
JavaScript contractors or staffers to come on board and develop / maintain you
client code and have to always have a Scala developer for that job as well
which is a magnitude of time and expense different.

The underlying notion of Scala to X ie Scala Native has lots of potential but
Scalajs is more of a segue.

~~~
JohnnyConatus
Seconded. I love Scala but when I hire for Scala devs there are so few that I
just hire the smartest developer I can find with FP experience and their first
task is learning Scala.

If I was starting something now I'd be tempted to use TypeScript if I wanted
one language on the front-end and the back-end.

------
cromwellian
The comments on jsinterop with respect to GWT are stale, GWT has a rich non-
JSNI based JsInterop system now, as well as a generator that can read Closure
and Typescript files and produce typed Java interfaces and classes for calling
external JS. It even converts Java8 lambdas directly into JS functions and the
reverse.

Also, the design restrictions to ban runtime reflection in GWT are a codesize
decision. Allowing reflective calls basically inhibits optimization and forces
the retention of tons of metadata.

The Deferred Binding mechanism is essentially dependency injection before DI
and annotation processing existed, because GWT hails from 2007. We now
recommend using Dagger2 for DI, and Annotation Processors for code generators,
so that the system of _compile time reflective calls_ is all part of the
standard tool chain.

In the era of mobile browsers, I think 100k is a bridge too far for a hello
world, especially in the developing world, so restrictions to the JRE runtime
which allow much greater code pruning are a necessary evil. It hasn't really
prevented an enormous amount of code sharing.

For example, Google Inbox shares 70% of its Java code between Web, Android,
and iOS (via J2Objc)

------
CuriouslyC
Scala is a cool language, but I can't help feeling that Javascript has a very
strong culture around it that pretty much dooms adoption of things that don't
feel "Javascript-y". I think the strong commitment to being a Javascript
superset is the reason Typescript is blowing up the way it is.

~~~
smrtinsert
absolutely agree. they nailed it by repurposing any js dev as a potential ts
user. part of the reason ill be pushing ts soon at my current position.

------
asciihacker
The livecoding with ScalaJS was especially impressive:
[http://www.lihaoyi.com/post/TalksIveGiven.html#live-
coding-s...](http://www.lihaoyi.com/post/TalksIveGiven.html#live-coding-
scalajs)

------
k__
3 things I don't like about Scala:

1\. It's based on the Java platform.

2\. It's excessive use of operator overloading.

3\. Mad implicit conversions all over the place.

(yes, I exaggrated a bit ;))

~~~
atemerev
1\. Java platform is excellent. Also, Scala.js is now Scala for JS platform,
and scala-native is coming soon.

2\. Have you seen languages like APL or J? Now that's operator overloading.
'+' is just a symbol, meaning a lot of different things even in mathematics.
All meaning is a product of convention.

3\. In modern Scala, implicit _conversions_ are discouraged unless you know
what are you doing. Besides, Scala IDEs are excellent in showing applied
implicits anywhere in the code (you do use an IDE, right?)

~~~
k__
Thanks for the reply :)

1\. Java platform is overengineered, everytime I had to set up stuff like
Maven, I missed the easy JS days.

2\. True story, I can infer what a '+' between two strings means, but what
about all the non-intuitive operators? (List concats etc. pp.)

3\. Not a big fan of IDEs. More of an editor dev, but good to know ICs are now
discuraged. I got myself "Programming in Scala" back in the days and it seemed
to me, that the Scala makers thought of IC as Scalas killer feature :D

~~~
oldmanjay
Not using an IDE for JVM-based languages is sort of like using pliers to drive
screws. You can do it, but it's tiresome.

~~~
saosebastiao
I used to only use plain editors until I started using scala, after which the
benefits of an IDE became readily apparent. Unfortunately, all of the IDEs for
scala are relative shit compared to their support for Java.

It would be nice to be able to run an integrated debugger (as opposed to a
port connection from an SBT spawned JVM), integrate directly with SBT (as
opposed to having to run it side by side), provide a full featured REPL (not
the neutered version with no completion and poor editor integration), as well
as functional import organization, dead code identification, refactoring
suggestions, real linting, real code formatting, working extract refactorings,
etc..

~~~
atemerev
Well, _the_ Scala IDE currently is Scala plugin for IntelliJ IDEA (works in
Community Edition, which is free and open source). All these features work
there.

------
grok2
The author explains his reasoning for using Scala.js well and what he says
makes me tempted to learn Scala as the "language-to-rule-them-all"!

------
harveywi
Scala-js is fantastic for all of the reasons mentioned in the article. It is
one of those tools that has become indispensable when I write web
applications. Here is a web app that I built using scala-js:

[http://experimental.worldcat.org/vandrmapping](http://experimental.worldcat.org/vandrmapping)

------
eggy
Very nice article. I am itching to play around with Scala.js because of it.

I had chosen Purescript over Elm, since I have read about Elm being
constricting once you move outside of most of the examples use cases.

------
s_m
Great article. I'm not a particularly sophisticated Scala user but I love
using Scala.js for all the reasons described in this piece. Thanks for all
your work on it!

------
lihaoyi
For all the people asking "Why didn't I talk about X"...

The real reason is that this 24-page heavily-researched blog post is already
too damn long lol

------
stijlist
It's a little strange that ClojureScript is omitted from the sections where it
compares favorably to Scala.js, e.g.:

> If you look at other compile-to-JS languages like:

> \- Google Web Toolkit which lets you compile Java to Javascript, > \- The
> Opal Ruby Compiler for Ruby > \- Brython, PyJS, Skulpt, Transcrypt or
> RapydScript for Python > \- Various flavors of C#-to-Javascript (Salterelle,
> Bridge.Net, JSIL) > \- Or Haskell-to-Javascript compilers (Haste, Faye) >
> You'll notice one thing in common: none of them have a standard way of
> writing code that runs on both their "original" runtime (JVM, MRI, CPython,
> CLI, ...) and on Javascript. And the reason why is straightforward: none of
> them are compatible enough, complete enough to really let you write "full"
> Java/Ruby/Python/C#/etc..

ClojureScript _is_ mentioned in the article, but only for this specious
comparison:

> Clunky Interop > Many other languages are not as fortunate. For example,
> here's how you create an element in ClojureScript, compared with Javascript

(let [paragraph (.createElement js/document "p")] (set! (. paragraph
-innerHTML) "<b>Bold!</b>"))

var paragraph = document.createElement("p") paragraph.innerHTML = "<strong>It
works!</strong>"

> Now, the conversion between these two snippets is mechanical, so it's not
> something you need a PhD to perform. Nevertheless, it is clear that using
> Javascript APIs in ClojureScript, while looking like ClojureScript, looks
> almost nothing like the Javascript it represents.

> This mapping is something that everyone who wishes to learn Clojurescript
> will have to internalize.

This seems misinformed at best - both Clojure and ClojureScript have interop
as a first-class concern, and interop forms are exactly the same between them.

I appreciate the work that Li's done, but I'm disappointed by what seems like
a rather disingenuous omission of the only other language which fulfills Li's
criteria.

Interop, IDE support (IntelliJ), parent language compatibility, static
optimization (judging by the payload size numbers, ClojureScript utilizes
dead-code elimination more effectively than Scala.js), performance
(ClojureScript immutable vectors are faster to build than JavaScript arrays,
far from the 1-2x Scala.js slowdown cited in the article!) - there is (and has
been - since 2011) a compile-to-JavaScript language that is in the same league
as Scala.js, and arguably eclipses it on many dimensions.

A language-agnostic comparison can't reasonably leave out ClojureScript.

~~~
methehack
I'm glad you pointed this out. That's way mal-informed for how you'd build
that DOM in clojurescript. I mean, you _could_ do it that way, but there are
libraries (like hiccup) that make it more natural.

Here's an example of a react component from the re-agent tutorial
([http://reagent-project.github.io/](http://reagent-project.github.io/)),
e.g., but you'd build straight html in the same-ish way using a library:

    
    
      (defn simple-component []
        [:div
          [:p "I am a component!"]
          [:p.someclass
            "I have " [:strong "bold"]
            [:span {:style {:color "red"}} " and red "] "text."]])

~~~
lihaoyi
The point wasn't to show how to build HTML fragments, the point was to show
javascript interop.

You _could_ create a nice wrapper-library around anything in any-language,
really, but that misses the entire point of that example: to show how
interoperability is when you _haven 't_ wrapped a nice wrapper-library around
everything.

------
saskurambo
Also haxe have nice features like scala.js bu have a c like syntax
conservative and is more practical. Big interaction with externs js with
external types definition, dynamics and untyped blocks. And can interact with
npm, webpack, closure and browserify. Js code generated is really small

------
dk8996
This is such a cool tool, being a Scala developer and not really loving
writing JavaScript. The only thing is that creating binding for JavaScript lib
sounds like a bit of a pain.

------
kevindeasis
What's a good way to learn how to use other languages in the browser asides
from javascript?

~~~
raquo
For Scala.js there are a lot of resources, e.g. [http://www.lihaoyi.com/hands-
on-scala-js/](http://www.lihaoyi.com/hands-on-scala-js/) is a good start.

~~~
kevindeasis
How does scala get embedded in the browser? I can't seem to find it on that
document?

I know you can use asm.js but it looks like they're not using asm.js

~~~
whateveracct
What do you mean? It gets compiled to vanilla JS. You can use sourcemaps to
link to your original source file for debugging as well.

~~~
kevindeasis
I was looking for this:

>It gets compiled to vanilla JS

thanks

