scala.js - Scala.js 会生成小包吗？

Question

虽然我喜欢 Scala 这种语言和 Scala.js 这个项目，但我对最终 JS 包的大小感到有些迟疑，即使是在 fullOptJS 模式下也是如此。

我的迫切需要是创建一个小型库以在浏览器中使用。> 150kb 是一个很大的要求，并且可以说是像 BuckleScript/ReasonML 这样的类似工具承诺快速执行和小包。

Scala.js 会在可预见的未来开始生成更小的包吗？

Answer 1

简短的回答：不太可能。

在设计语言时，总是需要做出权衡。特别是，跨 JavaScript 和另一个目标交叉编译一种语言通常会导致一系列或多或少相互冲突的目标。例如，生成“惯用的、可读的 JavaScript”通常与生成“高度优化的 JavaScript”不一致。

在那个领域，Scala.js 的主要设计目标是，按重要性降序排列：

1. 与 JavaScript 的互操作性：调用和被 JavaScript 代码/库调用的能力。
2. 与 Scala/JVM 的兼容性：除非使用固有的特定于平台的 API（例如线程），否则相同的 Scala 代码应该与 Scala/JVM 和 Scala.js 一起编译，并以相同的方式运行。
3. 运行时性能：生成的代码应该尽可能快。
4. 代码大小：生成的代码应尽可能小。

虽然代码大小绝对是一个问题，但正如您所见，它在主要设计目标列表中的位置非常低。这意味着代码大小问题通常会屈服于列表中的其他问题。

特别是，它经常与兼容 Scala/JVM的要求不一致。事实上，Scala 有一个相当大的标准库，尤其是集合，并且该库的许多部分相互依赖。这意味着一旦您使用 Scala List，您的代码就需要标准 Scala 集合库的重要部分。标准库的这一部分使大多数重要的 Scala.js 程序的重量超过 150 KB。

由于上述条件（设计目标 + 集合库相互依赖）在可预见的将来不太可能改变，Scala.js 也不太可能突然产生更少的代码。

严格来说，可以编写一个仅产生 10 KB 或更多的 Scala.js 应用程序。但为了做到这一点，您必须非常小心，永远不要使用集合库的任何部分。例如，您应该在任何地方使用js.Arrays、js.FunctionNs 和js.Promises，而不是Lists、=>functions 和Futures。此时，Scala.js 不再是 Scala，因此您最好使用另一种语言（例如，BuckleScript）。