5 ms·

Why does it exist at all?

ferbivore 9y ago
Possible reasons: * Facebook is trying to improve the frontend stack out of the goodness of their hearts. * Facebook is trying to drag their website into the 22nd century by abandoning JavaScript. * Facebook wants to make the whole world dependent on their software and/or their patent grant. * The React and Reason teams got drunk together one evening and this is the outcome.
- chenglou 9y ago
  I work on Reason and I used to help with React * Yeah! I know I'm pure-hearted at least * JavaScript will be around for a long time. Our stance is more gradual improvement than world-breaking changes all over the place. I'm still trying to phrase this correctly, because sometimes when Reason gets mentioned, the immediate reaction is "wow they're gonna rewrite everything again, kids...". Our interop story is pretty damn good. Please check it out! * See ReasonReact's license =) * The more successful Reason is, the less we'll drink. Kidding Our discord channel is at discord.gg/reasonml. I think we're a bunch of pragmatic and nice folks. It'll take time for people to understand our stance, but blog posts like these really help showing what we're doing.
yebyen 9y ago
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
- hazza1 9y ago
  Another Facebook project Flow gives similar if not as comprehensive benefits whilst staying in JavaScript.
  - yebyen 9y ago
    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/ https://flow.org/en/docs/usage/
    - hazza1 9y ago
      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/ https://flow.org/en/docs/types/comments/
    - Touche 9y ago
      No, Flow is not JavaScript, it's a superset.
    - Raphael 9y ago
      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/syntax-flow/ https://babeljs.io/docs/plugins/transform-flow-strip-types/ https://babeljs.io/docs/plugins/transform-flow-strip-types/
jasim 9y ago
Immutability, functional programming, and types. We're already using immutable values in Javascript thanks to React. This takes the form of manually cloning objects before mutating them, or using immutable-helpers, or immutable.js. This lets us reason about the data flow easily, and more importantly, allows React's shouldComponentUpdate do dirty check using fast reference equality. Functional programming - in FP languages, all functions are curried by default. So you don't need the awkward `bind` function to use it. Add extremely light weight function definition syntax and tail-call optimizations, and we have a language with first-class functions. Types - The adoption of Flow and TypeScript has brought to light a pent up need for some structure and sanity when writing large codebases. ReasonML is OCaml, and it has a very powerful and sound type system. Since Immutability, functional programming, and Hindley-Milner type systems are becoming ever more necessary to build complex front-ends, it makes a lot of sense to simply use a language that was designed for it. OCaml in its current form has been around for more than 20 years, and the research and other languages that influenced, is even older. It is a fun beautiful language that lets you focus on the shape and structure of your data front and center.
- Touche 9y ago
  > Types - The adoption of Flow and TypeScript has brought to light a pent up need for some structure and sanity when writing large codebases. Just noting that types have been around in programming longer than 2012 (when TypeScript first came out).
  - rco8786 9y ago
    Didn't get the impression OP meant otherwise. Read it more like "large javascript codebases" where types weren't possible before.
    - Touche 9y ago
      Yeah, it's just funny how the JavaScript community is all jumping on the types bandwagon right now and acting like it's some new discovery or something.
mambodog 9y ago
If your question is about why one would use Reason, Reason is an interesting alternative to Javascript for building web front ends (though it also can compile to very fast native code for backend/systems use too). Some things I feel are an improvement over Javascript + Flow or Typescript are: - immutable data structures built into the language (and more conventionally used) - real pattern matching on types, 'variant' types (like enums in Rust) - better dead code elimination (helps to keep browser payload size down) - you can use expressions everywhere (allowing more flexible code style than Javascript) - currying/partial evaluation - under the hood it's really just OCaml, which has benefitted from many years of development and improvement
haches 9y ago
If you'd like to play around with Reason a bit, you can give a try here: https://codeboard.io/projects/17520?view=2.1-3.0 https://codeboard.io/projects/17520?view=2.1-3.0

Possible reasons: * Facebook is trying to improve the frontend stack out of the goodness of their hearts. * Facebook is trying to drag their website into the 22nd century by abandoning JavaScript. * Facebook wants to make the whole world dependent on their software and/or their patent grant. * The React and Reason teams got drunk together one evening and this is the outcome.

chenglou 9y ago
I work on Reason and I used to help with React * Yeah! I know I'm pure-hearted at least * JavaScript will be around for a long time. Our stance is more gradual improvement than world-breaking changes all over the place. I'm still trying to phrase this correctly, because sometimes when Reason gets mentioned, the immediate reaction is "wow they're gonna rewrite everything again, kids...". Our interop story is pretty damn good. Please check it out! * See ReasonReact's license =) * The more successful Reason is, the less we'll drink. Kidding Our discord channel is at discord.gg/reasonml. I think we're a bunch of pragmatic and nice folks. It'll take time for people to understand our stance, but blog posts like these really help showing what we're doing.

yebyen 9y ago

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

hazza1 9y ago
Another Facebook project Flow gives similar if not as comprehensive benefits whilst staying in JavaScript.
- yebyen 9y ago
  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/ https://flow.org/en/docs/usage/
  - hazza1 9y ago
    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/ https://flow.org/en/docs/types/comments/
  - Touche 9y ago
    No, Flow is not JavaScript, it's a superset.
  - Raphael 9y ago
    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/syntax-flow/ https://babeljs.io/docs/plugins/transform-flow-strip-types/ https://babeljs.io/docs/plugins/transform-flow-strip-types/

jasim 9y ago

Immutability, functional programming, and types. We're already using immutable values in Javascript thanks to React. This takes the form of manually cloning objects before mutating them, or using immutable-helpers, or immutable.js. This lets us reason about the data flow easily, and more importantly, allows React's shouldComponentUpdate do dirty check using fast reference equality. Functional programming - in FP languages, all functions are curried by default. So you don't need the awkward `bind` function to use it. Add extremely light weight function definition syntax and tail-call optimizations, and we have a language with first-class functions. Types - The adoption of Flow and TypeScript has brought to light a pent up need for some structure and sanity when writing large codebases. ReasonML is OCaml, and it has a very powerful and sound type system. Since Immutability, functional programming, and Hindley-Milner type systems are becoming ever more necessary to build complex front-ends, it makes a lot of sense to simply use a language that was designed for it. OCaml in its current form has been around for more than 20 years, and the research and other languages that influenced, is even older. It is a fun beautiful language that lets you focus on the shape and structure of your data front and center.

Touche 9y ago
> Types - The adoption of Flow and TypeScript has brought to light a pent up need for some structure and sanity when writing large codebases. Just noting that types have been around in programming longer than 2012 (when TypeScript first came out).
- rco8786 9y ago
  Didn't get the impression OP meant otherwise. Read it more like "large javascript codebases" where types weren't possible before.
  - Touche 9y ago
    Yeah, it's just funny how the JavaScript community is all jumping on the types bandwagon right now and acting like it's some new discovery or something.

mambodog 9y ago

If your question is about why one would use Reason, Reason is an interesting alternative to Javascript for building web front ends (though it also can compile to very fast native code for backend/systems use too). Some things I feel are an improvement over Javascript + Flow or Typescript are: - immutable data structures built into the language (and more conventionally used) - real pattern matching on types, 'variant' types (like enums in Rust) - better dead code elimination (helps to keep browser payload size down) - you can use expressions everywhere (allowing more flexible code style than Javascript) - currying/partial evaluation - under the hood it's really just OCaml, which has benefitted from many years of development and improvement

haches 9y ago

If you'd like to play around with Reason a bit, you can give a try here: https://codeboard.io/projects/17520?view=2.1-3.0 https://codeboard.io/projects/17520?view=2.1-3.0