Scala.js会生产小捆吗？

Question

虽然我喜欢Scala这个语言,而Scala.js就是这个项目,但即使在fullOptJS模式下,我对最终JS包的大小也有点偏差.

我迫切需要创建一个在浏览器中使用的小型库.> 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集合库的重要部分.这部分stdlib是大多数非平凡的Scala.js程序重量超过150 KB的原因.

由于上述条件(设计目标+集合库的相互依赖性)在可预见的未来不太可能发生变化,因此Scala.js同样不太可能突然产生更少的代码.

严格来说,可以编写一个只生成10 KB或更多的Scala.js应用程序.但是为了做到这一点,你必须非常小心,不要使用集合库的任何部分.例如,您应该在任何地方使用js.Arrays,js.FunctionNs和js.Promises,而不是Lists,=>function和Futures.此时,Scala.js不再是Scala,因此使用其他语言(例如BuckleScript)会更好.