Can JS module be merged with Belt module?

I am trying to learn ReScript and I find myself constantly switching between Js and Belt modules documentation.

This makes me think about ReScript not as a language but as a library for JavaScript that adds some things like types and more modules with duplication names in both modules (Array, Float etc.) similar to lodash. As a novice it’s pretty confusing.

In my opinion a language is something whole that has all the Std Lib (Belt) and I do not actually care if under the hood the compiler converts it to some other language and uses its Std Lib (JavaScript).

If there was only one Belt module - that would make learning and orianting in the documentation much easier for me and I think for more people.

Again it’s my personal opinion, but I wanted to share it.

Thank you.

See this and few comments below: What work we could benefit from the community directly?

Js and Belt modules provide different functionalities, So Js module is not going away. maybe Js can be submodule of Belt (Belt.Js).

1 Like

I think the best thing you can do to solve this issue is to write PRs that bring to Belt the functions you use from the Js module.

Please bear in mind that we are talking about core libraries that impact every single user, and every future user. I know Bob encouraged contributions on that front, but we need to be really careful on what changes should be proposed, and more importantly, which features should be shipped.

It’s easy to add features, but is impossible to remove them later on, so it’s a pretty big liability that shouldn’t be taken lightly.

4 Likes

Of course at the end of the day it’s up to Hongbo to decide what to include in what shape, but it seems that he wants to go in that direction and it’s good to see more community contribution!

1 Like

@ryyppy,

I think that unifying all the stdlib into Belt should not add new features, but make more order and remove duplicate modules.

Thank you @amiralies.

That looks exactly the thread I needed to find and read.

This one looks like a duplicate :slight_smile:.

1 Like

I am not opposing your opinion, I also want a simpler API surface and less context switching between Js and Belt. Just want to say that as soon as Js functionality is properly reflected in Belt, the old Js, Js2, Pervasives modules will still stick around for backwards compatibility reasons.

So from a documentation perspective, we will still need to document Js, Js2 and all duplicated Belt functions. Upside: We can completely ignore the old APIs. Downside: There will always be newcomers like you, asking why all these modules with seemingly duplicated functionality exist (especially when browsing older codebases).

1 Like

As someone looking at supporting a thousand+ files in Reason syntax for an unknown period of time (or being asked to convert them), I do not find it any additionally burdensome to support (or convert) the currently confusing standard library situation to something more straightforward.

As it is, even I am forced to play ‘go fish’ for functions to operate on standard data structures like Array. I can also recall several instances of coworkers writing bindings or replicating in Reason functions that were already available because of the current situation. I suspect most newcomers are even more confused.

@ryyppy – As a newcomer to a programming language I prefer “deprecated, use X” as opposed to needing to filter an array and looking high and low. My personal journey involved Reason Docs, Bucklescript Docs, Array module api docs, Js module, Belt module (Old docs, so it was not obvious at all I needed keep), Pervasives module, giving up, then wrote bindings for it, then saw keep mentioned in discord later when someone asked the same question there.

It’s not that bad anymore, but those sorts of issues were way more frustrating to me when I started out than syntax nuance.

For what its worth, I’m perfectly ambivalent about what any of it is called, so long as its all in one module, although I do want to point out “belt” doesn’t make much sense anymore.

4 Likes

The project I work on is getting up there - 500 source and a couple hundred interface files. It’s going to expand a lot this year.

This happens all the time :joy:

We’re dealing with this problem by creating our own little company standard library that combines Belt and Js in ways we prefer, adds in some bs-webapi, and also has ports of convenient functions from our big TypeScript codebase. There are zero open Belt lines in our project, and only a small handful of direct Js references.

3 Likes