I group Reason (Ocaml/Bucklescript) and Fable (F#) together because F# is OCaml's sibling language on .Net. They're very similar. The two projects have similar philosophies, specifically to bring their ML variant to the javascript ecosystem in a module-by-module mixed-language fashion instead of having the language be its own island in the browser. Neither has a particularly large community but the Reason guys have been doing a better marketing push this month, at least from my perspective.
I'm not familiar with the latest ECMA and standards updates and I suppose I don't really know what modern JS actually looks like, but the example on this page[1] doesn't look like syntactically valid JavaScript to me.
If you write code that has to be compiled before it turns into JavaScript, there's another benefit though... it's that you can never accidentally promote code to a server that hasn't already been vetted by the type-checker!
Or, even run it locally! You are guaranteed that the type checker has been run before the code hits a runtime environment.
Looking at Flow, I'm seeing there's a tool `flow` that you run any time you want to check the types. I think there's a background process way to run flow, that mitigates this issue somewhat... but if Flow is in fact implemented to always be syntactically valid JavaScript, that could be a bad thing.
No way. Even in its most basic, untyped form the React model simplifies things all the way down your app pipeline. Errors that used to be common tend to naturally vanish over time.
We have some fairly sophisticated JavaScript that is part of our app, but we haven't drank any of the modern JS kool-aid yet, the only validation we're really using is a suite of feature tests written with Cucumber and Selenium/Chromedriver.
So if you have some JavaScript and it is functionally important to a feature that you've tested, it will show on the CI result if it's broken... but if there's a JavaScript error during the test that didn't stomp on the behavior tested by the feature, you'd never find out about it unless you happen to be watching the Inspector console at the time.
I am not a react developer but I have heard that one of the common complaints about React is ... that it's not Elm, or in more explicit terms, in case you don't know anything about Elm, ... that it's very easy to write code that will break if you poke it the wrong way.
In a static typed language such as Elm (or Reason, based on skimming briefly)... when you get input that can mutate the state of the program, it comes in the form of a message. The messages are typed, so you know what values to expect.
If you write a switch/case statement that handles a message type, the compiler will balk at you if you change the values that the message type can have, without updating the case statements that operate on that type to cover them all.
tl;dr: because runtime errors are a b