| HN Mirror

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.