BuckleScript

BuckleScript

  • Docs
  • Try
  • API
  • Community
  • Blog
  • Languages iconEnglish
    • 日本語
    • Español
    • Français
    • 한국어
    • Português (Brasil)
    • Русский
    • 中文
    • 繁體中文
    • Help Translate
  • GitHub

›Recent Posts

Recent Posts

  • A story of exception encoding in BuckleScript
  • What's new in release 7.3
  • Generalized uncurry support in BuckleScript 7.3
  • Announcing bs-platform 7.2
  • Loading stdlib from memory

BuckleScript 3.0

April 16, 2018

bs-platform 3.0.0 is released! Go get it. This is a great release.

Highlighted features:

  • OCaml/Reason boolean are finally compiled as JS boolean! Due to historical limitations, OCaml true/false was compiled to 1/0 in JS. This caused quite a bit of confusion for newcomers. It now compiles to JS true/false. Special thanks to Cristiano for all the hard work.
  • New object type feature. This is an experimental and potentially much better way to bind to JS objects that potentially obsoletes the need for a few other APIs. Please see the linked docs and help us test it!
  • raw now accepts a function declaration with an unsafe string body: let f = [%raw (a, b) => "return a + b"] (OCaml syntax: let f = [%raw fun a b -> "return a + b"]). This makes embedding escape-hatch raw JS code even easier for the compiler to optimize for speed and readability, as you've indicated that the raw code block is a function, with specific numbers of arguments.

The usual changelog is here.

We've been working on the BuckleScript compiler for almost four years now; meanwhile, the OCaml type checker itself has already been engineered for almost three decades. After all this of work, we believe that BuckleScript has reached a stable and reliable stage.

Below is a list of to-dos that we will work on in the future. Suggestions welcome!

  • Upgrade the OCaml version. OCaml is quite a stable language; there are not too many changes between BuckleScript's OCaml version and latest stable one. Nonetheless, it's good to keep up with the OCaml ecosystem.
  • A uniform representation for local modules/global modules. Currently local modules are compiled to array, while global modules are compiled to ES6/CommonJS/AMD modules (the cost of local modules is low though, thanks to aggressive inlining).
  • Continue improving Belt. Some initial nice numbers here.
  • Enhance FFI to allow creation of idiomatic, type safe JS classes.
  • Introduce a debug mode to enhance the printing of OCaml data structures.
  • Performance. The compiler performance and generation of more performant and readable code is always our top concern.

Thank you for all the support so far!

Recent Posts