Scaling from the back to the frontend

Interview: Compiling Scala to JavaScript with Scala.js

Elliot Bentley

We speak to Sébastien Doeraene, student of Martin Odersky and creator of an experimental Scala to JS compiler.

Scala is already one of
the biggest languages on the JVM, and with new project Scala.js, it’s breaking into the
browser, too.

Created by Sébastien Doeraene, a member of Martin
Odersky’s Scala team, it joins a growing array of languages that
can compile to JavaScript, including Coffeescript, TypeScript, Dart
and ClojureScript.

Having introduced the project to the world in
June, Doeraene last month christened the current build as v0.1. We
spoke to him about the project’s origins and aims for the

JAXenter: What inspired you to start working
on Scala.js?

Doeraene: It was not my idea,
actually. When I applied for a position in LAMP, the Programming
Methods Laboratory at EPFL, aka the Scala Team, Martin Odersky
suggested that I work on a JavaScript compiler backend. As I
already had experience with writing a backend for Scala targeting a
dynamically typed language (with my
previous work on Ozma
), I had a head start to make this happen.
Besides, I love Scala, and I love writing compilers, so I was super
excited to start on this project. The fact that a lot of people are
really excited about this is also highly motivating.

How long has it been in

I started the development of Scala.js in February 2013. So it
has been 10 months, as of this writing. The first two months were
focused on writing the initial prototype of the compiler. After
that, I spent two more months making it remotely usable for the
presentation at Scala Days in June 2013. Since then, I have been
improving tooling support, like development in IDEs and integration
in sbt, the canonical build tool of Scala, as well as size of the
generated code.

Recently, I have welcomed two active contributors,
Haoyi Li, who has made a great job at improving the
developer-friendliness of Scala.js, and Jonas Fonseca, who
contributed benchmarks and a test suite. A week ago, that small
team was joined by Tobias Schlatter, an engineer hired in LAMP to
work, in part, on Scala.js.

This is a fairly young project, but the enthusiasm
displayed by contributors and the resources that Martin Odersky is
willing to allocate to this project give me a strong hope that it
will be a complete success.

How stable is Scala.js now? The official site
warns that it is “still experimental”.

As you can imagine, this is hard to measure. To give
you figures, we have a test suite that tests the specifics of
Scala.js, most notably the interoperability with JavaScript, as
well as bugs previously fixed. With a little more than 100 tests,
it is still fairly small but it keeps growing.

We also have an experimental branch that runs the
whole Scala test suite (several thousands of tests) with the
Scala.js compiler and a JavaScript interpreter. Currently, about 50
% of these tests pass. Of the other 50 %, many are not genuine
bugs, because they test features that Scala.js simply does not
support: REPL, reflection, Java collections, parallel collections,
etc. We are still working on identifying the needles in the
haystack that are the genuine bugs, so that we can fix them and
eventually integrate the entire Scala test suite as part of our
continuous integration.

Now, to give an overall feeling, I believe Scala.js is
a successful prototype that deserves to be assessed in toy
applications and personal projects. People who have been testing it
all agree on being amazed at how well it does work. I would not
recommend it for a project at work, though, unless your team is
willing to accept the obvious risks of using an early alpha

What’s the advantage of using the same
language both server and client-side?

First and foremost: code reuse between client and
server. Often, we need to share logic between the client and the
server. The obvious simple example being form validation logic, but
it goes beyond that. Having the same language on server and client
allows to reuse the same code for this shared logic, provided it
does not rely on platform-dependent parts. One of my personal
projects currently contains 4,000 lines of Scala code, of which
3,500 are cross-compiled to run both on a desktop with a JVM and on
the Web with JavaScript.

Would Scala.js appeal to client-side
developers without existing Scala experience?

That is an excellent question. I do not know if Scala.js would
appeal to them, because Scala is so different from the typical
tools available for client-side development that it will probably
not be accepted. However, I definitely think it would be profitable
to them if they made the leap, as soon as the application reaches a
medium size. The Scala language is so much more powerful, easy to
work with, and fun to work with! The same has applied to people
jumping over from Java, and now it might be the occasion from
JavaScript developers to discover Scala too.

Would you like to see a Scala VM within the
browser, and cut out the JavaScript middleman

No, I would not. The world has come far with the
JavaScript story, and I really see JavaScript, along with HTML and
CSS, as an excellent platform for Web development. Also, we saw
what happened to the JVM in the browser, didn’t we?

What I would like to see in a future version of
JavaScript, however, are a few more features that would allow more
exact and easier translation of some concepts. For example,
JVM-like primitive data types, i.e., integers of various sizes.

comments powered by Disqus