Hacker News Reader

Comment by yebyen | Hacker News Reader

Static typing and compile-time checking are two very good reasons, same reasons you'd use Elm.

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

View on HN

The tradeoffs between Elm and Reason/Fable are that the former is Pure and the latter have imperative escape hatches. There are benefits to both. Elm has a neat time travelling debugger built in and enforces semantic versioning via their package manager. Reason and Fable have much tighter integration with the javascript ecosystem. This tends to lead to differences in community package philosophy with Elm mostly maintaining its own package repo (own vdom system, own date lib, etc) with the occasional ports for interacting with popular javascript libs while the more nascent Reason/Fable communities tend to write interface definitions and call the JS directly (e.g. they use React for vdom).
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.

Another Facebook project Flow gives similar if not as comprehensive benefits whilst staying in JavaScript.

Does it really stay in JavaScript though?
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.
[1]: https://flow.org/en/docs/usage/

Realtime checking is trivial with the appropriate IDE extension and you can always put the type annotations inside comments -
https://flow.org/en/docs/types/comments/

No, Flow is not JavaScript, it's a superset.

Babel has a bunch of extensions to JavaScript that are widely used. Sounds like it just finds and strips out type annotations.
https://babeljs.io/docs/plugins/syntax-flow/
https://babeljs.io/docs/plugins/transform-flow-strip-types/

> that it's very easy to write code that will break if you poke it the wrong way
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.

I need to learn React, I need to learn Elm... I don't really know what I'm talking about, but on the internet nobody knows you're a dog.
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.

How is this different from Typescript?

Reply on news.ycombinator.com