What work we could benefit from the community directly?

Hi all,
Someone asked me offline where they can help to make the project work better, thanks! There’re lots of things that the community could help, e.g, documentation, blogging.

Here I will try to list something that’s mostly actionable, it will change accordingly. (Note the ReScript below means all syntaxes supported since they can easily be interchangeable)

  • Enhancing Belt.
    Previously, it’s a small lib since it’s very hard to make it work on all platforms in an efficient way, you could make it work but you have to pay the price.
    Since now we settle on JS platform, it would make sense to add more functionalities needed
  • Building Libs without bindings, build our own ecosystem.
    We make bindings really easy in ReScript so that you can ship very quickly.
    However, to get all the benefit of ReScript, it makes sense to deliver libraries purely written in ReScript itself.

Feel free to share your feedback below so that I can update the list.


Certainly Belt could be enhanced and more functionalities added. However, already at this time, Belt is not only extremely useful, but also consistent regarding naming conventions (camelCase) and argument order (pipe first).

The latter cannot be said of the Js modules, unfortunately, and IMHO to reduce confusion for newcomers it would be more important to finally clean those up before focusing on enhancing Belt. See the discussion in https://github.com/rescript-lang/rescript-compiler/issues/2975 (and also Why not rename Belt too?).

For both Belt enhancement and Js enhancements, some guidance would be needed:

  • What is your vision / where do you want to take these?
  • What are the concrete steps for which contributions are welcome?

Speaking of the vision for Belt, are you considering opening the Belt module by default (instead of the Pervasives module)?

1 Like

I think it would be good to focus on enhancing Belt for short term and focus on a brand new STDLIB which is polished and feature rich. It might be good to unify Stdlib/Js/Belt note that current state is really confusing for newcomers. questions like “what is the difference between Array, Belt.Array, Js.Array, Js2.Array are asked over and over”


Is there a significant difference between creating a new STDLIB and bumping a major version of Belt with breaking changes?

Of course, so far Belt seems to have no semver of its own, so it might be a problem.


What breaking changes do you foresee for Belt @hoichi?

I agree I would love to merge Js modules with Belt, would you be open to PRs that would bring some functions from Js to Belt @Hongbo?

1 Like

I am thinking of that eventually making Belt the only one to be exposed to users (but it takes time).

What is your vision / where do you want to take these?

I think we can start now.

What are the concrete steps for which contributions are welcome?

We can start from small, adding missing functions, modules, e.g, Belt.String. Also we can move some high quality modules in stdlib to Belt, e.g Stdlib.Random etc (It’s pretty good but tweaked for 31 bits…)

Speaking of the vision for Belt, are you considering opening the Belt module by default (instead of the Pervasives module)?

Yes, eventually


Yes, I shared your confusion, see my comments with cknitt


I am not sure if I follow you. Do you have any breaking changes in mind?

yes, this is also my thoughts

1 Like

From what i can tell, Js modules are for the most part 0-cost bindings, while Belt modules tend to have runtime. It would be nice to maintain some separation between these groups to avoid users incurring a runtime when all they wanted was an external.

The major difference between the Js.* modules and Belt.* modules is that they offer completely different functionality.

Js is responsible for zero cost bindings to the JS apis, e.g. running Js.Array.map really compiles to a [].map.

Belt on the other hand is a stdlib that offers functionality beyond the JS apis, sometimes with better perf, immutability or better type safetiness aspects (get vs getExn). It also means that it will pull in the belt library when you use it in your code (which is not zero cost).

Therefore one is a binding, the other one is a library.

I wouldn’t even know how one would unify that?


Oh, now I see that amiralies meant Stdlib the module, not just some standard lib to replace Belt. Sorry for the confusion.

1 Like

I am curious is belt size a practical problem for you?
It’s written in a style that’s very friendly for dead code elimination


It’s okay to have both Belt and Js since there’s a clear difference between these two, I meant remove other extra modules eventually, as I said having Std, Belt, Js, Js2 all together is confusing.

I’m also thinking about what if we move Js into Belt, so if we open Belt old Js module will be overridden.

1 Like

I know they don’t have the same philosophy, but as a user I’m mainly interested in the features more than what happens under the hood, especially since the overhead of Belt seems very light, it’s usually more performant and I’m always amazed by how well it tree-shakes. I only use Js module for the few functions I don’t find in Belt, like the String module and a few functions of Array like joinWith. If such functions get ported to Belt (either by just copy-pasting them or by reimplementing in rescript if it brings better perf) I would totally forget about Js module and only use Belt.


Is there something we should keep in mind when publishing them (other than including the keyword rescript in package.json)?

Is there a special place where they should be published besides npm? Will there be something similar to redex just for ReScript libs?

1 Like

No, npm is probably the only place you should be publishing to… it would be great if especially smaller libraries would keep their number of files low, so it’s easy to vendor them with a single file within consumer codebases if necessary,

We will implement a simple package discovery page (a way simpler version than redex) on rescript-lang.org hopefully somewhere around October!


Some folks may not have tree-shaking in their build system. Also it’s nice to be able to know when reading someone else’s code “ah this is Js.* so I know it’s just a binding and nothing more”.

We could keep Js module for some use cases but I’d still like to have a more feature complete standard lib.


For those interested, I created a pull request for the few functions I wanted to add to Belt.Array: https://github.com/rescript-lang/rescript-compiler/pull/4734

1 Like