Address comments.

Author: sjrd

_posts/2020-10-27-scalajs-for-scala-3.md

@@ -5,21 +5,26 @@ by: Sébastien Doeraene
 title: "Implementing Scala.js Support for Scala 3"
 ---
 
-Today, the JS platform has become an integral part of the language.
+These days, the JS platform has become an integral part of the language.
 Yet, until last August, support for Scala.js in Scala 3 was close to non-existent.
 A first preview was shipped in Dotty 0.27.0-RC1, with support for the portable subset of Scala and native JS types.
 Since then, support for non-native JS types was added and will ship as part of Scala 3.0.0-M1.
 The only missing feature left is JS exports, which we will implement by the next milestone.
 
 What did it take to add Scala.js support in Scala 3?
-How come we managed to do the necessary work in less than 3 months, whereas Scala.js for Scala 2 took 7 years to mature?
+How did we manage to do the necessary work in less than 3 months, whereas Scala.js for Scala 2 took 7 years to mature?
 Those are questions we aim to explore in this post.
+
 After some background on the architecture of Scala.js for Scala 2, we will cover which components had to be rewritten for Scala 2, and which ones we could reuse.
-We will see that only a small fraction required a rewrite.
+We will see that only a small fraction of the codebase required a rewrite, namely the compiler plugin (weighing about 11% of the total implementation code of Scala.js).
+Other components like the JDK implementation, the linker and optimizer are reused as is.
+Last but not least, we could reuse the test suite as well.
+
+This post explores how Scala.js is implemented, and not so much how it is used, although no compiler knowledge is required to enjoy this post.
+For readers mostly interested on what Scala 3 has to offer to Scala.js *users*, stay tuned for an upcoming blog post.
 
 ## Background: the Scala.js architecture
 
-When we use Scala.js, it can sometimes appear a bit magical.
 In a simple sbt project, the only difference between a JVM project and a JS project can be as short as this one-liner:
 
 ```scala
@@ -37,6 +42,8 @@ Two settings, and suddenly `run` or `test` will compile the codebase to JavaScri
 There are many components that contribute to this behavior.
 Just looking at the compilation pipeline, there are already 4 components involved: the compiler plugin for scalac, the linker, and the artifacts for the Scala standard library and the JDK subset that is implemented.
 
+![Scala.js compilation pipeline](/resources/img/blog/scalajs-for-scala-3/compilation-pipeline.svg)
+
 ### A compiler plugin
 
 When compiling a Scala.js codebase, the .scala source files are compiled with scalac, augmented with the Scala.js compiler plugin.
@@ -48,7 +55,7 @@ Traits have been lowered to interfaces; lazy vals have been desugared; nested cl
 This is how Scala.js is able to keep up-to-date with all the versions of Scala 2, and be available on the same day as new Scala releases.
 Not all compile-to-JS languages have that property!
 
-### `.sjsir`files
+### `.sjsir` files
 
 .sjsir files are similar to .class files, although they are AST-based (instead of stack-machine-based) and contain features dedicated to JavaScript interoperability.
 The .sjsir format and specification is independent of Scala, its compiler or its standard library.
@@ -59,12 +66,44 @@ While we have a proof-of-concept for Java, it is nowhere near usable, however.
 
 .sjsir files have binary compatibility guarantees similar to those of .class files.
 With a few exceptions related to JS interop annotations, if changes to a .class files are binary compatible, then the changes applied to the corresponding .sjsir files are also binary compatible.
-This allows Scala.js codebase to meaningfully use MiMa to check that they do not break their binary API.
+This allows Scala.js codebases to meaningfully use MiMa to check that they do not break their binary API.
 
 The Scala.js linker (optimizer) takes the .sjsir files from the application and from all the transitive dependencies.
 In particular, the .sjsir files that are built for the Scala standard library and for the JDK subset.
 The linker optimizes all of them together, then emits one .js file for the entire codebase.
 
+### Aside: What about TASTy?
+
+Inevitably, talking about the Scala.js IR raises questions about TASTy.
+TASTy has in fact no impact on the implementation of Scala.js for Scala 3; nothing good, nothing bad.
+And yet:
+
+* `.sjsir` files are an intermediate typed AST-based language for compiling Scala code.
+* `.tasty` files are an intermediate typed AST-based language for compiling Scala code.
+
+When described as above, one may wonder what is the relationship between the Scala.js IR and TASTy.
+Could we not just compile from TASTy to JavaScript?
+
+The answer is no, we could not.
+TASTy has a very different level of abstraction than the Scala.js IR.
+
+| TASTy | Scala.js IR |
+|-------|-------------|
+| full Scala type system | erased type system (like the JVM) |
+| no interoperability knowledge | specific JS interop features |
+| complex Scala features (traits, inner/local classes, lazy vals, etc.) | flat classes and interfaces, no fields in interfaces, simple fields in classes, etc. |
+
+During the compilation pipeline, the compiler first type-checks and elaborates Scala source code into a TASTy-level representation (even in Scala 2, although it is not TASTy itself).
+Then, a few dozens of phases successively transform that representation to eliminate Scala features and erase the type system.
+It is only at the end of that process that Scala/JVM produces `.class` files while Scala.js procudes `.sjsir` files.
+
+We *can* compile from TASTy to JavaScript, but that does not take away the fact that we have to perform all those phases again.
+There is no shortcut.
+The best way to do that is to reuse the phases that are already implemented in the compiler, of course.
+From there, we still need to compile the lowered representation of the compiler into JavaScript, and the best way to do that is through the Scala.js IR.
+
+Therefore, from the point of view of implementing Scala.js for Scala 3, the presence or absence of TASTy is irrelevant.
+
 ### Components of Scala.js core
 
 The components involved here have the following sizes (not counting test files):