Melange 1.0: Compile OCaml / ReasonML to JavaScript(buttondown.email) |
Melange 1.0: Compile OCaml / ReasonML to JavaScript(buttondown.email) |
The challenge with ReScript is that the authors really were focusing on the JS ecosystem, and didn't care at all about OCaml. Their fusion with the ReasonML community didn't make a whole lot of sense. ReScript is a much better language now that it has split than it was then, if you look solely through the lens of a better JS.
But, as Elm and other compiled-to-JS languages have learned, Typescript has gotten good enough that other languages might not be sufficiently better than TS to attract enough interest to have a vibrant community. Doubly so since the JS-interop story isn't nearly as good in ReScript as it is in Typescript (though it's much much better than in Elm).
However, the aim of writing programs in OCaml which compile to nice JS and also native OCaml, and allowing both client and server to be written in OCaml, remains valid and interesting (and I would argue was held back by js_of_ocaml, the pre-existing way to do it). So I think there is something interesting here, though it isn't a ReScript competitor except tangentially.
Though I cannot really understand where ReasonML (a JS-like syntax for OCaml) fits into this - if the target is OCaml devs, than surely the ReasonML syntax stuff is not valuable anymore?
Your perspective on the project is exactly how we think about it: Melange provides the tooling for fullstack (@davesnx likes to call them Universal) Reason/OCaml applications.
I suspect my time in Clojure(Script) has heavily influenced how I look at a "Language of the System"[1], and that's effectively what we're trying to do here.
Re: ReasonML, I very much understand the sentiment. In my mind right now, ReasonML is only there to provide JSX and reason-react support. I suspect we'll eventually write a JSX PPX for OCaml and stop using ReasonML down the road (fairly longer term).
To add a counterpoint, though I'm in the minority, I think ReasonML is really really important to keep OCaml accessible to a larger amount of people. I work in a very cross-platform context and program in 5/6 different languages a month, and despite having a lot of experience with different syntaxes, OCaml is just weirdly unique enough that it's hard to immediately transfer my skills. I haven't written OCaml seriously in a while, and even looking back on my own code, for example the PPX I wrote https://github.com/AriaFallah/ppx_str 5 years ago, I can't really read it without zoning in and thinking quite hard vs. just flowing.
I find Fable is good too and generated code is very readable.
https://ersin-akinci.medium.com/confused-about-rescript-resc...
BuckleScript, when it was called that, was incredibly compelling for me. This was in part thanks to being blazing fast, unlike TypeScript. So I am pleased to see a spiritual successor.
However, Melange seems to head in a good direction too and I guess it would be amazing for people who are already familiar with OCaml and want to integrate with libraries and codebases there. So I think both projects are valuable in their own right for different use-cases.
First, we had BuckleScript, that compiled OCaml to JavaScript to bring the OCaml type system to the Web.
Then we had Reason, that brought JS syntax to OCaml, so it's easier to grasp for JS devs.
Seemingly, some people didn't care about OCaml at all, and forked (I guess?) Reason to ReScript, that focused on JS compilation. They also added a few syntax changes in the process.
Now, the remaining (pre-fork) Reason people created a new(?) compiler that's an alternative to BuckleScript, and compiles OCaml and Reason to JS.
While I appreciate the effort, and think ReScript and Reason are superior to TypeScript, I totally understand why it didn't get as popular as this superiority implies.
Some people are just bent on doing their thing, the way they want it.
I prefer the current situation to the one where the ReScript people took over Reason and changed its focus and syntax.
Last discussion I could find was from 2018 [1].
With this Melange release, we're hoping to somewhat revive ReasonML and channel some folks back to the community from the perspective of a vertically integrated platform[2] that has seen major investment in the past few years.
[1]: https://github.com/reasonml/reason [2]: https://ocaml.org/docs/platform
If you want to revitalize the project, please start updating the blog again :-)
There has been a bit of activity on fixing bugs on refmt and polish the experience, no plans for big features so far but we will keep working on it.
We will update documentation from either reason-react and reason to highlight the integration with Melange soon.
OCaml is the most fun I've ever had writing code; seeing this after the whole Re* rebranding death spiral makes me hopeful that fullstack OCaml is still a possibility.
Thank you!
Both of those came up before melange.re when searching for a hello world example.
AFAIU, ReScript is a new language that offers an alternative to TypeScript.
Melange approaches the problem from the perspective of compatibility with OCaml / ReasonML. We've focused very hard on vertical integration with the OCaml Platform[1] and we're getting all the benefits with this release!
That said, both communities are fairly small, and I don't doubt that somewhat competing projects have some impact on community. From our perspective (the Melange team), our goals fit a specific use case, and e.g. Ahrefs, one of the leading SEO engines in the world, is using Melange[2] in production to power all their web experiences.
[1]: https://ocaml.org/docs/platform [2]: https://tech.ahrefs.com/ahrefs-is-now-built-with-melange-b14...
Elm & PureScript I believe solved this problem.
You can accomplish width subtyping with OCaml's "polymorphic variants", which could be used to emulate TS union types more flexibly than traditional sum types.
What are the features of Elm and Purescript that help model TS that OCaml doesn't have?
This way, you get all the benefits of having a native toolchain and build system, and a great integration with modern JavaScript with e.g. npm or yarn.
The biggest differences between Elm and ReScript/ReasonML as language features are bindings, JSX and purity. Bindings in Elm are cumbersome and limited (on purpose) while in ReScript/ReasonML are easy, more feature complete and a little more fragile. JSX is exactly as React, while Elm doesn't have it; some people prefer it, some people don't. I love it. Purity in general terms makes Elm more strict while ReasonML/ReScript allow impurity when needed, still most APIs enforce functional style, immutability and proper data structures.
Regarding community, there's drama everywhere not sure If I can do a good job here. Maybe community size Elm is much bigger than others, but they need to reinvent most of tooling that is done in JS and ReScript/Reason takes advantage.
I encourage to not rely on anyones opinion about what's better, because you listed 5 languages with opposite directions.
Try it out yourself and decide based on users/team needs. Cheers.
Purescript has, I think, some of the most interesting things going for it from a FP language, as its effects system paired with the very nice support for JS objects through Record means you can build effects systems like "this function reads from the DB" vs "this function writes to the DB", or "this function accesses a single user's data" vs "this function is multitenant". The FFI story is also very straightforward IMO.
ReScript feels close to Elm in that it's very focused on a straightforward usage of ML and isn't trying to be fancy. I haven't messed with it in a while but honestly OCaml is pretty straightforward and lets you easily fallback to simple imperative tricks in a way that Clojurescript and Purescript don't.
I think if you want to go full FP, Purescript has the most interesting stuff to bring to the table (and because it's not lazily evaluated the mental model is not hard). ReScript has the easiest onboarding IMO... and Clojurescript is good if you're into Clojure/lisp-y stuff in general. But they're all very distinct flavors and it's ultimately a bit of an aesthetic choice IMO
In order of time programming in each language:
Elm: no, because of the JS interop (didn't even try it).
Clojurescript: really slow REPL, uses Google's closure compiler which had it's own problems (I don't remember what these were, but something with modules). Both Emacs and VS Code (Cider/Calva) did have to many small errors and inconveniences using CS. All in all it had been an unpleasant experience.
ReScript: The language itself is OK-ish (I would have preferred OCaml syntax), the compiler is fast as OCaml. The generated JS is really readable. One year ago there had been no async and the documentation had been missing stuff like functors (I've "found" them at the Rescript forum). But in the end it didn't have enough advantages over TS to cancel out TS' _way_ better developer tools/integration or even Purescript, but this may have changed in the last year (async has been added and functors are now documented, as I've just seen). On the other hand, I would nowadays use Melange instead, I don't see any reason[what a pun!] to use Rescript any more.
PureScript: It is a better (strict) Haskell (with less features). I've used (non-hook) Halogen, I don't know about the React bindings. I had never made an web app (progressive or not) before, so I had to learn everything starting at 0. This has been the result, which has been a quite smooth experience: https://github.com/Release-Candidate/Notoy-PWA#purescript
You also make a good point. I didn't go into too much detail about ReasonML in another comment, but I know Jordan (@jordwalke) has plans for a ReasonML v4 [1] with slight syntax improvements. I don't currently know the status of that work, however, but I think we'll want to make progress soon.
So the TL;DR is more that ReasonML is not going anywhere, especially since Ahrefs have a huge ReasonML frontend codebase [2].
[1]: https://github.com/reasonml/reason/pull/2605 [2]: https://tech.ahrefs.com/ahrefs-is-now-built-with-melange-b14...
some real problems with jsoo are (non exhaustive list)
- "heavy" FFI (both in term of setup and syntax)
- the output is a big single .js file, which doesn't allow reloading of a single component and doesn't integrate well with stuff like webpack
- slower compilation time
- lacking documentation for the javascript audience