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

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

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

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

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.

Inline Feedbacks
View all comments