Relatedly, though it’s young, there’s reasonably-typed, which is BuckleScript-specific instead of jsoo-specific; and which works in the ‘opposite direction,’ so to speak. It’s not very complete as of yet, though; they have a test-suite which runs across a huge body of existing JavaScript typing definitions, and only about half of them are passing.
I’m relatively new to the community (just logging into the forums for the first time right now, though I’ve been active on GitHub, and occasionally IRC, for the last year or so), but maybe I can shed some light on the “readable output” thing.
With traditional compilation targets, the overall product that the output of the compilation is fitting into is generally under the control of the author choosing the aforementioned tool doing the compiling: if you’re writing a C program, you’re maybe consuming one or two huge, monolithic libraries; and chances are, you’re contributing little-to-nothing back upstream to the OSS community. That is, if you decide to switch to, say, OCaml, for some portion of your code, you’ve nobody (at least in spirit) to answer to except yourself and your team of collaborators.
The backend (and slightly more recently, frontend) JavaScript communities, though, are super-tight, in the OSS sense: chances are extremely good that some, if not most, of what you’re writing is going to go straight back up on npm for somebody else to consume — and crucially, for somebody else to probably contribute back to. My experience over many, many years, is that 2010-onwards JavaScript, Node, and npm have some of the most prolifically active and incestuous OSS models I’ve ever seen. (… not to say that this is a good thing, or that it leads to good software … I mean, this one-function package has 10,000 dependants, 200 commits, and 84 pull-requests …) When JavaScripters write code, they expect many other JavaScript developers to read that code — many of them possibly new, hobbyist, or young.
Correspondingly, when things like CoffeeScript (which, by the way, pioneered this “readable compilation-target” thing as a whole) started to come along, the many, many people who didn’t write CoffeeScript would be rather unhappy when they’d come across a project they wanted to use, (and I repeat: as a JS dev, “to use” implicitly means “to contribute back to”) and it would be incomprehensible to them. Well, eventually, between the complaints thereof, and the preponderance of compile-to-JS-language projects out there that were seeing subpar or nonexistent contributions from the community that ran them, we eventually ended up with a collective mindset that the code you push to npm must be readable, plain, ES5. You could write CoffeeScript, TypeScript, hell, Clojure if you wanted, as long as the JavaScript was the canonical, hackable source of the projuct.
Anyway. History aside: a huge, huge selling-point of the ReasonML ~thing~ (specifically BuckleScript, but nobody following the hype seems to actually call it that — it’s all just ‘Reason’), is that the Hardcore Nerd who’s actually into this stuff, doesn’t have to convince the ~100 other developers on the OSS project that ‘hey, we need to stop what we’re doing, all of you need to learn a new language, and we need to rewrite the entire project in a functional language!’ It’s sold, bottom to top, as something that you can add to existing JavaScript codebases incrementally: start out with one file — just go rewrite that horrific spaghetti parser in Menhir without asking anybody, compile it down to JavaScript that’s supposedly indistinguishable from your collaborators’ hand-written code (especially after it, like all the other JS in the project, goes through the opinionated auto-linter the team mandates …). Hell, you can even git filter-branch the “weird”, “freaky”, neckbeard-code entirely out of the branch you submit the pull-request against. :P Everything in the ecosystem they’re building seems focused on that: bsb fares extremely weak when compared to Dune; but is strongly designed to cohabitate with multiple other build-systems existing in the same project.
Thanks to these same priorities, one of the very best things BuckleScript brings to the table, is exactly the opposite of what @Yaron_Minsky wrote above: BuckleScript is happy (sometimes too happy …) to abandon OCaml compatibility, ease of use from that direction, and intuitive-to-old-hat-OCamleers semantics, to map more cleanly to JavaScript semantics. That Reason file I described above? It’s expected to return a first-class JavaScript Promise, handle all cooperative concurrency internally using the JavaScript event-loop, use obviously-polymorphic JavaScript debugging/printing tooling instead of complicated-but-runtime-typerep-free ppx_show magics, cleanly map both records and hashmaps to JavaScript’s heavily-overloaded ‘Object’ instances … so on, so forth. Yes, this has a lot of obvious downsides, when viewed from the OCaml side, which has plenty of perfectly-good, immutable, performant data-structures and types. That’s not the point — the point is literally writing JavaScript-semantic code, that naturally and directly manipulates these JavaScript concepts, in a sound hindley-milner inferrant environment that lends itself to rapid refactoring, y’know?
(All the above isn’t to say I, personally, subscribe to a lot of these viewpoints, by the way. I’m just neck-deep in the Reason hype-wave, and this where, why, and how I see other JavaScript devs looking into ML for the first time due to Reason, whereas js_of_ocaml garnered absolutely no interest whatsoever from the other side of the fence.)
tl;dr: JS devs were hurt, bad, by their last relationship with a compile-to-JS tool. They’re often extremely sensitive about a tool demanding holistic ownership of their projects, contributors, and mindspace.
tl;dr 2: it’s all about how it’s being marketed. to nobody’s surprise. :P