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.
Thanks!
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).
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”
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)?
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.
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.
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.
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”.