BuckleScript development plans for next half
In this article we will explain what we are doing now and what we plan to improve in next half (Dec-May), we would also like to hear your feedback so that we can adjust accordingly.
Keep in mind that the development team is a very small team, so we have to prioritize things instead of working on every feature.
What we are doing
In the last couple of month we are busy upgrading the OCaml compiler from 4.02.3 to 4.06.1, the good news is that the upgrade is almost done.
We plan to ship it soon by the end of this year, at the same time, we will still maintain the current version of the compiler until we feel the new compiler is as good as the old one.
Note the upgrade is not easy work since the internals of OCaml compiler changed significantly in the last few years. Our upgrade strategy is also quite conservative, it works by conditional compilation so that the bsc compiler actually work with both versions, the benefit is that in this case, we are not in a messy state, the bug fix of bsc compiler can still benefit two branches.
But the reward is also huge, there are a bunch of optimizations and nice features coming alone in the recent releases of the OCaml language, to name a few: inline records, local exception and hex notation for floats etc. More importantly, this is a great move to engage better with OCaml ecosystem: the previous old version compiler imposed some maintenance overhead for OCaml toolchain, we can make better use of OCaml toolchain after such upgrade.
What's next
Making better use of the new compiler internals
The upgrade is divided into two stage, the first stage is focused on no regression so that we can ship it.
Afterwards, we have plans to make better use of the more info rich IR in the new release. Thanks to the flambda introduced after OCaml 4.03, more information is passed down to the lambda IR where BuckleScript take from. For example, user can annotate functions inline or not with inline attribute, we can make better use of such information.
In newer versions of OCaml compiler, the block and array is more distinguished we will investigate whether we can make use of it to provide better data representation for OCaml datatype.
Another interesting direction is to see if we can encode module in a consistent style: as an JS dictionary for both global modules and local modules.
Improving the usability of BuckleScript toolchain
BuckleScript is focused on making better use of JS ecosystem and provide values to ship JS code in production (produced by BuckleScript).
Making Bucklescript toolchain more lightweight
Currently it is still too heavy for users to provide JS libraries from BuckleScript, since clients need to install bs-platform which requires a lot of disk-space and native compilation in some platform. We will investigate if we can distribute the native compiler without using npm.
Separate the compiler from stdlib may also help draw the contribution to the stdlib/belt library.
Improving the usability of bsb
Currently the bsb is restricted by the npm directory layout, the generated JS artifacts is also restricted by it, we will see if we can relocate the JS artifacts or provide more flexibility for users.