@hanting003
2016-09-14T14:44:19.000000Z
字数 3913
阅读 1209
现在软件行业——从互联网行业到传统软件领域——有一个很明显趋势: JavaScript Platform，这个唯一的跨平台语言正在吞噬着所有软件领域（因为mobile的崛起Java 已经不再是一个跨平台语言了)：
BuckleScript 早期是我的个人项目，为什么我要写一个这样的编译器呢?
上文已经提到，我已经意识到了JavaScript，这个唯一的跨平台语言正在吞噬着所有软件领域，虽然JavaScript平台很诱人，但是“动态语言难于构建大型程序”基本上已经是业界共识，一旦程序规模上来了，基本上就只能Write Only。
我所在的公司有上千万行JS，维护起来基本上就是噩梦，在原来的Hack上添加新的if else Hack。而工业界真正有工业强度而且和JavaScript 交互良好的的编译器是微软的TypeScript 编译器，但是，我希望能够有一个比TypeScript更快更好的编译器，BuckleScript因此诞生了。
9月8日，BuckleScript 1.0发布，此时，我从事BuckleScript 的编译器的开发已有近一年。这是个值得纪念的时间， BuckleScript通往未来的路上，有了更强的马达。
BuckleScript已经被一些公司所采用，例如，Facebook的某些产品用到了它。
BuckleScript有着自己的优势，主要体现在以下几点：
BuckleScript 不是一个新的语言，它是把一个已经存在将近30年的语言OCaml编译成可读的JavaScript。而OCaml本身对很多平台存在native 的后端支持。像go一样，OCaml可以编译出汇编代码到iOS、Android、Windows、Linux、MacOS。而TypeScript只有JavaScript 一个后端。
拥抱JavaScript 并不代表我们就要抛弃native 平台，当我们需要更快更可靠的性能的时候，我们可以有更多的选择，比如做工具链的时候: TypeScript 的编译器同样也是用TypeScript写得可以跑在浏览器里也可以泡在node上，但是它跑在node上得时候就比BuckleScript编译成汇编跑慢不止一个数量级。
TypeScript是一个JS的超集，它存在很多历史包袱。而微软引入TypeScript更多的是作为一个工具来使用的比如IDE的代码补全，相对安全的代码重构。而这个类型的准确从第一天开始就不是它的设计初衷，以至于Facebook自己设计了一个相对更准确地类型系统Flow__. 而OCaml的类型系统是已经被形式化的证明过正确的。也就是说从理论上BuckleScript 能够保证一旦编译通过是不会有运行时候类型错误的，而TypeScript远远做不到这点。
用过TypeScript的人都知道，TypeScript的类型推断很弱，基本上所有参数都需要显示的标注类型。不光是这点，像对函数式编程的支持，高阶类型系统GADT的支持几乎是没有。而OCaml本身是一个比Elm,PureScript还要强大的多的语言，它自身有一个非常高阶的module system，是为数不多的对dependent type提供支持的语言，polymorphic variant。而且pattern match的编译器也是优化过的。
BuckleScript不只是一个编译器更是一个optimizing compiler: 它做过的优化有: Code motion, Purity analysis, Cross module inliner, Constant folding/propagation, partial evaluation Strength reduction, escape analysis。我们做的benchmark显示同样的immutable data structure 比如facebook immutablejs__, BuckleScript的实现有时候要快两到三倍不止。而相比之下TypeScript编译器并不会做任何优化工作。
总之，借用Bloomberg的说法，BuckleScript旨在通过以下几个方面，尝试解决用JavaScript构建的大型系统存在的问题：
与现有的其他JavaScript转译器比较，BuckleScript旨在提供更快的编译、可读和简洁的代码输出，保留和OCaml源码相同的模块结构。
将BuckleScript从最初版本升级到1.0版本，主要是稳定的外部函数接口设计和bug修复。
由于BuckleScript生成可读的JavaScript代码，JavaScript调用OCaml函数时不需要做太多的工作。我们已经花费了好几个月时间斟酌外部函数接口的设计，以方便用户从OCaml调用JavaScript。我们的目标是把OCaml这种表现类型系统（有一些BuckleScript定制的属性）的优势在不需要编写任何存根代码的前提下直接引入到JavaScript库模型。
主要的亮点有：
BuckleScript支持两种调用规范：uncurried（与JavaScript完全一样）和优化的curried调用规范（函数编程范式中使用）。
我们努力让JavaScript外部函数接口存在两种风格：一种是类似PureScript的功能性外部函数接口 ，另一种是对象外部函数接口，它采用OCmal表现对象类型系统实现。这允许我们严格模拟JavaScript结构类型。
我们还内置支持JavaScript this关键字的语义。
OCaml中一些独特的特性，如用于模型事件监听器的多态变体(polymorphic variants)。相比TypeScript，这给我们提供了非常有力的类型安全保障。
大家可以在我们产品见面会的介绍上找到更多BuckleScript外部函数接口的详细信息。
我们最近正在努力的一个目标是整合Reason和BuckleScript。Reason是由Facebook Jordan团队开发的，它是为OCaml提供的JavaScript类前端语法。
我正在和著名的ReactJS/ReactNative的作者Jordan 合作，希望能推出 Reason On React (Powered by BuckleScript) ，期盼这能够给BuckleScript 带来killer app。
而BuckleScript 本身的编译器是用OCaml写的，可以被编译成汇编和JS本身（压缩后大小700KB), 用户们可以自己感受下它的编译速度：OCaml to JavaScript transpiler playground。注意：汇编的版本比JS的版本还要快一个数量级。
由于OCaml的编译工具链是非常模块化的，我们的前端很容易从OCaml转向Reason。要强调的是，Reason不仅仅是语法。Reason团队也在努力改善OCaml中的工具，像构建系统、IDE等。我们一起共同努力。比如，BuckleScript外部函数接口的设计得到了Reason团队很多反馈。
BuckleScript未来的发展，我们制定了以下路线：