What are your thoughts around creating a repo like DefinitelyTyped that can publish bindings for popular libraries, with Rescript having governance over it?
In my opinion, something like @rs/jquery would make the Rescript a much more viable, and desired project to run with.
Look at this thread: ReScript real world expectations, libs and interop - #6 by ryyppy
PS: Are there really still jquery users? 
Yeah, more than any other framework 
.
I think some things should be taken pragmatically rather than idealistically. The average user wants something good enough rather than perfect. Rescript in general has moved towards a more pragmatic approach so to discount generalized bindings because of a puritan ideal seems inconsistent.
Ultimately, I think it would speed community adoption for people to be able to jump in and feel productive with an ecosystem that may not be ready for Rescript - much like Typescriptâs early days was.
That whole thread linked by dkirchhof has lots of good info (and lots of links to other threads with good info), but just a recapâŚgiant full-library bindings can be trouble.
Itâs interesting you mention that, as imo, writing bindings only for the particular stuff you need seems like the most pragmatic thing to do, whereas constructing bindings for a large library that will have to be consistently maintained seems like the more idealistic view.
That being said, if there is a good way to have mostly automated way to manage big binding projects, then that is a different story.
Typescript has a great type ecosystem that is pragmatic in the sense that it only has to be done once, and by someone that isnât necessarily you. How do you find having to write bindings for every single package you import pragmatic?
@types are curated by members of the typescript team, and other community efforts. Thereâs no automating it, but itâs worked out thus far.
Binding huge projects doesnât seem to be a problem there. I think something that Rescript could benefit from is having a way to override bindings the way typescript can. That way if you have a certain need in a niche situation, you can always override whatever binding.
Mostly because I donât write bindings for everything in every package, just a few functions from each library as I need them. So writing those bindings is quick. Itâs rare that I need the full api surface of every library Iâm using, so no need to write bindings for it, or depend on external bindings that arenât maintained. There are just the bindings needed for the project, and maintained within the project. (Which also letâs me keep them as close to JS as needed, or as type safe as needed.)
As you say writing bindings for all of jquery every project is probably a bad idea, but thatâs not what most of the bindings Iâve needed have been like. So of course, ymmv. And you could definitely be right and having a centralized thing could be good for Rescript.
Could be that part of the reason it works there is that the community is huge in comparison to Rescript. I canât say for sure as I come from OCaml not JS ecosystem.
Edit: And of course, you will see a good number of bindings published by rescripters, and in theory I could see the benefit of a central place for them.
I do agree that for the most part, you donât need to bind a whole project, but I think collectively, the community has probably wrote bindings for every major project out there. Like you said, centralizing and governing it with a curation for quality would make it nicer for the next person.
Planting DX trees is what, I think, makes a language prosper. The advancements Rescript has made recently will make it reach a tipping point, and making the onboarding process for new companies / devs to quickly get started will speed that up a lot
DefinitelyTyped comes with a very big downside which is: you can (and more often than not will) end up with types that are not actively maintained nor accurate enough to be used into any reasonable production ready software.
Itâs a really tedious process and ultimately makes you feel like âsomeoneâ didnât do their job properly. I would rather have a set of very limited yet accurate bindings for the given task than having a whole library mapped approximately and around author inconsistencies. Just think about how JSON.stringify or parseInt are typed, make it exponential and you can easily see the flaws in definition files and, subsequently, in project like DefinitelyTyped.
Perhaps, the âaverage userâ may not match with the âaverage ReScript userâ. What makes ReScript interesting is how different and more robust its type system is: if I want something with a reasonable to high degree of uncertainty I would probably still with TypeScript or, even better, with vanilla JavaScript instead.
Best!
I think to counter your points, you donât have to use the types if they arenât according to your needs.
Thatâs the point, if you want something good enough - then itâs available.
On your other point, Im not sure how easy it is to override bindings in Rescript are, but if work was done in that direction - it would make this all that simpler. If youâre not happy - override it
If the hypothesis is that itâd make it cheaper and easier to adopt ReScript, then Iâd say itâs more a matter of someone leading the initiative than anything else (itâs easy to get stuck bike shedding).
I think itâs a good idea, even though I personally tend to create bindings to what I need (though certainly not always).
EDIT: I think a previously suggested name was âReasonablyTypedâ, which I personally find rather amusing
@cvr I would happily contribute what bindings I have to an @rs repo. While writing bindings is pretty easy, I have a large project with a growing bindings directory that is becoming an eyesore. Would much prefer if I could just reuse existing bindings and focus on my app
As @lessp says someone just needs to take the first step. It doesnât need to be perfect project or famous at start, we can just start with contributing what we have in a community style until it eventually grows
What stops you from publishing bindings for a particular library in a separate package to gain some traction?
When I helped maintaining flow-typed, I realized how bad this concept of externally catered bindings in one place actually is. Maintainers not even using the JS libraries tried to put types on it, or merged PRs without knowing if the changes actually reflect reality. On the other hand some PRs were just stuck bc nobody knew if changes would break things. The actual JS libraries (even flow versions) were constant moving targets, so users were regularly stuck on particular library versions all the time or sacrificed sanity regarding misaligned types / runtime. Lots of complexity and OSS effort for not much gain. IMO the only major advantage of flow-typed was that the CLI vendored the bindings into your project, which allowed local modification if needed (defeating the point of having flow-typed as a single source of truth). ReScriptâs binding repo would suffer the exact same issues (library version, ReScript version, binding version).
Additionally, ReScript bindings are not a 1-1 mapping thing either and you canât write highly generic types, so you will eventually be torn apart by API discussions up to a point where ppl start to vendor / fork the definitions (without ever merging back to upstream).
I feel like this would actually cause newcomers to think that ReScript is just too complicated to work with, or they get discouraged to learn essential parts of the language. This idea (including generating bindings from d.ts files) has been popping up many times in the past few years, and whoever tackled it started to realize that itâs too much work and silently abandoned the project.
The community would benefit a lot by having more ReScript app show cases that map to common library scenarios, so ppl can just copy / paste them and adapt things until they work. Building a tool to make vendored binding files easier to manage for multiple projects would IMO also be useful.
I know this was probably not a serious name suggestion, but if this project ever should happen due to someoneâs initiative, Iâd politely ask to not call it âReasonablyTypedâ. We finally got to a point were we successfully detached from the Reason umbrella and I donât want to explain again why Reason != ReScript 
. Itâs a fun name, but I can already see that this will cause a lot of confusion.
What stops you from publishing bindings for a particular library in a separate package to gain some traction?
I think what I like most of the @types package is discoverability, thereâs a ton of value in being able to do npm i @types/package -D for just about anything. With rescript thereâs a little bit more of a barrier to finding what you need, where Iâll often opt for just writing my own bindings without searching google first. Then in a self fulfilling loop, I also donât finish and publish my bindings, because I feel nobody would find them.
What about a central place to search for rescript packages? It doesnât need to be complex, something like awesome rescript but for bindings. Could go into a json file and then deploy a simple UI search bar onto github pages
Wow this is sweet, I had no idea this existed
DefinitelyTyped has definitely been a major contributor to the success of Typescript. Copy pasting is not enough for he majority of people, and friction like that adds up to the detriment of Rescriptâs adoption.
I think itâs wise to learn from the success of other languages, and incorporate it into ones own ecosystem. having an @rs package scope requires ownership from the rescript team - and it requires governance so that a reasonable standard(not perfect) of quality is placed.
The end result is that 80% of bindings are useful, and that goes a long way.
Something that Typescript is very good at is allowing overriding of bindings, so if we put effort in that regard - maybe this can end up being a great success.
Manually handling bindings is a thing of the past. As has been reported on this thread many times, it has been tried. Thatâs the first naive idea eveyone had like 3 years ago. Itâs 3 years later and still it did not happen. A big complex conversion mechanism is also a thing of the past.
A little helper can write bindings for you, and weâll explore this more next.
It requires buy in from the rescript team, as did Typescripts implementation. It has never happened because the rescript team does not want to do it for one reason to another.
Thatâs understandable, and fair. Though I would not say it is a faulty idea, since itâs Typescript is a huge example of itâs success
One small comment from me. When I see rs I think of rust not rescript.
Thatâs definitely a fair assumption: that putting unlimited resources in that one direction, it might work out.
I donât think anyone said that they know exactly what would happen.
What I understand people say is: nontrivial resources have been put into this and it has not paid off.
The suggestion that will likely be tried next is: try to get to the desired outcome by putting as few resources as possible into this but do it differently and be creative.