[dmkolobov]

I have no skin in the game w.r.t to OCaml/Reason/etc. I do wish compile-to-JS languages would give up on the readable Javascript thing. I think ClojureScript nailed it with their reliance on Google Closure's aggressive optimization mode __because__ it produces obfuscated, highly optimized output.

Purescript also shares this goal, and it is a bummer, performance-wise, in older browsers that don't handle currying and various other "readable" representations well.

Worse still, if your target output is readable, then someone might start touching the compiled runtime objects with Javascript and then... god help you as you watch the guarantees of your fancy type system unravel before your very eyes.

[spyder81]

"readable output" isn't really about being human-readable, except in unrealistic example cases. The bigger benefit is shared data types; this helps immensely with JS interop.

https://rescript-lang.org/docs/manual/latest/shared-data-typ...

[testcross]

I feel like the dev team is using "readable output" to mean both "human-readable" and "shared data types" depending on the situation. And it creates a lot of confusion.

[yawaramin]

Spyder81 is partly right, 'readable' doesn't mean 'human-readable' per se, it means rather that the compiler tries very hard to produce output JS that looks like idiomatic, hand-written JS. This means things like:

- Uncurrying functions

- Compiling OCaml modules to idiomatic JavaScript objects

- Compiling OCaml record values to idiomatic JavaScript objects

- Compiling tail recursion to idiomatic while loops

- And so on.

> someone might start touching the compiled runtime objects with Javascript and then... god help you as you watch the guarantees of your fancy type system unravel before your very eyes.

That's exactly what genType is for--it produces JavaScript, TypeScript, and Flow interfaces for ReScript output code so that people in the JS world can consume it transparently.