Given that you have a free choice (i.e. you could potentially choose ReScript in your project), what are the reasons that you sometimes decide not to? I’m thinking that it’s worth discussing recurring reasons from two perspectives:
To lower the threshold for adoption
To understand common pain points
For me, I have two main reasons. The first is that the tooling does not feel entirely mature yet. This is expected as ReScript (the language, community, tooling, etc.) is still in it’s infancy.
More relevant, I feel that bindings are a major pain. Even more so because I find that how I write the bindings sort of depend on how I intend to use the library. Potentially, this could be because of incompetence on my part, don’t know.
I would gladly use ReScript way more if the bindings issue was resolved for me.
Please feel free to be as explicit as possible about these issues. For example - what exactly it is that makes the tooling not feel entirely mature. This is very important for us as we prioritise what to work on next.
Sure. The vscode plugin which I use with Emacs, for example, crashes regularly. Error messages in the compiler are often very confusing and not at all very explanatory. The stdlib is still not stable eg ReScript core. Some things in React do not feel natural at all even though they may be basic features. The documentation is incomplete.
I could go on but I don’t think it’s very helpful. It’ll eventually get there and none of what I listed above is critique - the project is simply going through a very natural phase. I appreciate you tying it into developmental efforts though - you’re awesome for that!
The main gripe for me is bindings. Some time back I had an idea of an @types (NPM) similar thing for ReScript, but I’m not sure I believe in that idea anymore as I’ve come to realize that bindings are more fluid, since there’s no 1:1 correspondence. Could that be solved in a manner that also works well over time (i.e., doesn’t break every time I update a package), ReScript would likely always be my language of choice for Node projects where I have the choice,
I think its important to look at the alternative options as well a.k.a Typescript. In this case, I agree about stdlib, which Typescript basically uses the JS stdlib.
However, the TS LSP crashes on me even more than the rescript LSP. It seems as though it is just a very difficult problem in LSP land. A quick restart of the Rescript LSP always fixes it for me.
I also think, withholding minor inconveniences like React.string, React.array, etc, React feels better. Resolvers feel like magic with Pattern Matching and the module system encapsulates components really well. Not having to manage imports is a huge plus for me in react land. Also the new JSX v4 stuff fixes a lot of the gripes I had with props and context.
I think bindings are a bit of a double edge sword. Remember, the recommended pattern emphasizes not being afraid of JS. If your bindings are becoming overly complicated, consider using JS to simplify the interface.
Ultimately I think my main problem is Rescript is a very different way of thinking to common JS. It’s hard to onboard users who aren’t familiar with Rust/OCaml/Haskall land
I would say the only thing really stopping me from using rescript in more areas is onboarding - reading the main docs is a good reference to get a general idea, but there’s still that leap from concepts to productivity that I’m not sure how to help on. The less familiar you are with FP ideas the more work it takes
The biggest reasons that make me think twice before using Rescript in a project:
VSCode extension is nice but the LSP is quite a bit of hassle to use in other editors. This would be mitigated by having it avaliable on npm. Also mac os complains about the security of the lsp analyzer, so it is not the best experience
Frontend-wise, everything is tied to the react ecosystem. I understand that JSX preservation is coming but right now this means being stuck with React, Next and webpack, which is… oof.
There is no documentation on testing, no clear path to implement it.
Better onboarding. The current docs are pretty good! But like @hellos3b said, it is a bit hard to go from explanation to project implementation. There are very few online resources, I’m lucky that Rescript is beloved by some here in Brazil and there are a lot of livestreams but non-portuguese speakers can’t really use that. Expanding on examples, tutorials and how-tos would help quite a bit. Svelte and Solidjs do a great job on teaching the concepts and features and could be a nice source of inspiration.
Having interactive examples that go beyond compiled output could be pretty nice for lessening the effort to get started.
Std lib is… kinda confusing. Js page says “use us instead of Belt if possible!” and Belt says “I’m safer!” and it is like… which should one really use? Why having two overlapping implementations? I’d understand if Belt added only things that simply are nowhere to be found in Js, given what the docs convey. String2 and Array2 being different for usage with pipe first or pipe last is… odd. Feels like complecting things and increasing the surface area for very little gain. Plus, inconsistent naming. Why is Js_typed_array.array_buffer snake_case-ish but Js.Array2 is PascalCase?
The auto completion of the ide is relatively weaker a lot than other languages like java, ts, scala, rust…
Aliased modules in function scope and more tiny scopes don’t have any completion or type hints.
Since i have converted my next.js based project from ts to resceipt totally(nearly 55k loc), the Rescript code base becomes too large, there are a lot of deeply nested modules, i can only alias the nested modules in the top level of my file module for normal completions and type hints, but that would pollute the namespace of my file module.
Our ide developer team is too small, only one person is contributing the vscode extension currently(not very sure, @zth@cristianoc). And the analyser part of rescript extension is written by OCaml, the debugger and printting tools of OCaml are not very useful, that make it too hard for me(or other rescript users) to contribute to our ide extension. May be it’s a good idea to write the whole ide extension with rescript itself.
As others here have mentioned autocomplete is weak and feels inconsistent. Highlighting of errors is odd - sometimes highlighting what appears to be empty space.
I keep retrying every few months, because otherwise I love the language and the type generation is fantastic. But the lack of solid IDE tooling is a dealbreaker unfortunately.
