IIRC from when I looked into it and got it working a few months back, you npm install bucklescript, wihch gives you a compiler to convert reason to JS, so to do any testing that actually includes a real world equivalent experience (such as include it in a sample webpage, maybe with React), you're talking about using webpack or something to bundle all the dependencies and steps into a deployment procedure.
Since it compiles to JS, and uses a JS lib and ecosystem to install the utilities that do the cross-compile, it's sort of like if to try out Python you had to first download and install a C compiler and C libraries used in Python, and compile python from scratch, just to try it out, because no pre-existing binaries, packages or installers existed. If that was the only way to try out Python (or Ruby, or Perl, or anything), you would get a lot less people trying it out, and a lot less willing to go through all that in their build chain (in case python updates, right?) if easier alternatives exist.
Just because your language compiles to another language, that doesn't mean to you get to ignore the on-boarding experience to that extent. At least not if you really want to succeed.
There's no ignoring going on. Reason exists on its own because it's not opinionated on what sort of app you're trying to build – frontend, backend, native, or some combination thereof.
> There's no ignoring going on. Reason exists on its own because it's not opinionated on what sort of app you're trying to build
I think either I wasn't clear, or you completely misunderstood me. My point, that Reason should have a standalone installer or package that gives you a working Reason as simply as possible without a whole build infrastructure required, is only bolstered by this statement.
I don't think it matters if it's the Reason-to-Ocaml targeted, or Reason-to-Javascript, or one for each, or one that includes both. Having to install one language, and then use tooling and package managing from that language to install another, strikes me as somewhat ridiculous in this day and age. just ship the entire tooling stack abstracted away.
No, I'm complaining it's not optimized for the person that just wants to try it out in any way. Not everyone is using npm or already has Ocaml on their system. Making them install that entire toolchain first to try our Reason locally, is sort of crazy, it's just not the crazy that's easily seen when the costs are already completely amortized because you're a Javascript or Ocaml programmer already.
And locally is important, since they might want to try a simple app with it, and not want to set up a whole Javascript dev toolchain with webpack. Sure, they might end up going that way eventually, especially if they choose Reason and or React and integrate it into their project, but for a test drive, requiring it is a large hurdle and a lot more to keep track of.
Reason's current distribution method is akin to Python requiring the installation of a C compiler toolchain so you can download the source and compile. To be sure, that's a wanted distribution method of an open source project like that, but they've rightly recognized that as the only distribution method it would hamper adoption, especially on platforms where that toolchain is harder to get set up.
I'm not even suggesting Reason go as far as that, exactly. I'm suggesting Reason ship a tarball/zip with a directory structure that includes Node and a set of pre-installed packages that provide Reason/Bucklescript. Installation instructions would include setting a few environment variables (altering PATH, telling Node where to look for packages). Or instead of Node/npm, provide Ocaml/OPAM with the correct packages pre-installed (although that might be slightly harder due to an increased amount of binaries as opposed to interpreted scripts as with JS). Or both in the same package, if it's not an excessive amount of work.
I understand it's a lot of work, but at a certain point, expecting prospective users to install a whole toolchain not for your language, but for the hosting language, just so they can test it out your language ends up being limiting. You've said that Reason isn't trying to be opinionated in what kind of app you're trying to build, but I think it's still being very opinionated in the exact process required to build that app. It's just that you allow for two opinions instead of one.
Hopefully that's clear enough, and you understand this comes from an actual desire to make Reason better. I spent a couple weeks in my spare time earlier this year evaluating whether Reason would work well for a new project I was starting, and I was extremely excited by the possibility of a shared front-end/back-end codebase that could be compiled to binaries when needed for performance reasons. That ended up not working out because I think the ecosystem isn't quite there yet for that exact need (e.g. a good framework and ORM that's mostly in Reason, and doesn't require converting from Ocaml to reason, etc), but a big takeaway I got from that was that as someone not invested in the Node module ecosystem that much, setting that up, and in a way that was repeatable and documented, is painful, and that ended up counting against Reason in the end because I would undoubtedly have to deal with that. That's not to say I wouldn't with what I'm proposing, but if I'm already on the Reason cheer squad that's less of a problem, language adoption-wise.
Everything I've heard suggests ReasonML is targeted primarily at developers currently using NPM and working in that stack. I don't think creators of a tool have a moral obligation to make it easy to use for everything. Most things have an intended focus, and some happen to be really good for all kinds of other stuff too. That being said, it does sound like it would be cool for it to be easier to install without that dependency.
FWIW, Scala and Clojure require the JVM to work at all, and both are pretty popular.
Since it compiles to JS, and uses a JS lib and ecosystem to install the utilities that do the cross-compile, it's sort of like if to try out Python you had to first download and install a C compiler and C libraries used in Python, and compile python from scratch, just to try it out, because no pre-existing binaries, packages or installers existed. If that was the only way to try out Python (or Ruby, or Perl, or anything), you would get a lot less people trying it out, and a lot less willing to go through all that in their build chain (in case python updates, right?) if easier alternatives exist.
Just because your language compiles to another language, that doesn't mean to you get to ignore the on-boarding experience to that extent. At least not if you really want to succeed.