7 ms·

A First Reason React App for JavaScript Developers

85 points by mambodog 9y ago

pavlakoos 9y ago
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
JasonSage 9y ago
I tried Reason out maybe half a year ago. To me, the exceptional thing which the Reason project lacks is a polished developer experience. It feels very much like a hacked together combination of technologies which requires the developer to install several things just to get a working compiler. I think before I would try Reason again there would need to be some effort put into streamlining setup and managing of the developer environment. EDIT: Downvoted? Let's hear some feedback and other opinions maybe?
- quicksnap 9y ago
  There has been a lot of work in making the developer experience as awesome as possible. I know that, for the core team, it is one of the highest priorities. While this tutorial doesn't use the official bootstrap, you can see it here: https://facebook.github.io/reason/gettingStarted.html https://facebook.github.io/reason/gettingStarted.html -- It's only a few lines in your terminal! The integration with VSCode is pretty amazing, too.
- mambodog 9y ago
  At this stage, the only thing you need to do to get Reason to 'work' is to use Create Reason React App (when targeting the browser). The language/compiler itself is installed as an npm package(!). The only other things to install are the CLI tools (again, just an 'npm install' away) and optionally a plugin for your editor.
megamindbrian 9y ago
For what reason do we need yet another dialect of JavaScript?
- modarts 9y ago
  It's not a dialect of JavaScript, but rather a typed, compile to js language.
- girvo 9y ago
  It's a "dialect" (sort of) of Ocaml, with all of the beauty that is its type system and Functor (not thing.map, parameterized modules!) that can compile to JavaScript via Bucklescript.
jaequery 9y ago
this might be the tipping point of js fatigue for most React/JS developers. we can only hope this doesn't catch on, fingers crossed.
- TheAceOfHearts 9y ago
  If it's ends up being notably superior in multiple ways, and you already have a properly configured and flexible build toolchain in place (i.e. Webpack), adding support should be trivial. I haven't personally used it, but a quick search landed me on the bs-loader [0] repo, which claims to work with both OCaml and Reason files. As I understand it, and I'm not very familiarized with Reason, the team behind the project is working hard to have a good interop story. We've seen the same thing with React's versioning scheme [1]! Going forward there shouldn't be horrible breaking changes, and in the cases where stuff must be broken, they appear to commit to providing a clear migration path that can be adopted gradually. There's probably plenty of good use-cases for using something like Reason. Should it be used everywhere? No, certainly not. But having worked on a reasonably sized JavaScript web app, my experience has been that it becomes increasingly difficult to maintain as it grows. Even with something like Flow or TypeScript, you have to think very carefully any changes. Luckily, the JavaScript ecosystem has modularized everything quite heavily, so you can usually contain things that end up being "bad ideas" and gradually chip away at em. The app I worked on wasn't even that large or complicated, so I have a very hard time wrapping my head around the challenges faced by engineers working on Facebook's scale. [0] https://github.com/rrdelaney/bs-loader https://github.com/rrdelaney/bs-loader [1] https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html https://facebook.github.io/react/blog/2016/02/19/new-version...
crucialfelix 9y ago
There is an online ocaml to js converter here: http://bucklescript.github.io/bucklescript/js-demo/index.html http://bucklescript.github.io/bucklescript/js-demo/index.htm...
IX_Hispana 9y ago
This, not unlike Elm, looks pristine, ivory-tower-ish to me. The examples are always neatly self-contained or consuming a real simple json API. They're fiddles. Fiddles always look neat. I think it would do these types of projects a lot of good to do something real using third party libraries. Convince developers and companies they're real, not toys. I still haven't seen a blog post explaining Elm along with a masonry library, socket.io, bootstrap, shopify, etc. Probably I'm not getting what's the real use case for these things. It can't be writing web apps.
- mambodog 9y ago
  I don't think Reason is like Elm in this way. Whereas Elm requires you to wholly buy in to the Elm world, Reason can easily be brought into a large existing codebase. Large chunks of messenger.com are written in Reason. I'm pretty sure that qualifies as a 'web app'.
  - IX_Hispana 9y ago
    Hey, thanks for the reply. What would you say is a good opportunity in a project to sneak some Reason in?

85 points by mambodog 9y ago

pavlakoos 9y ago

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

JasonSage 9y ago

I tried Reason out maybe half a year ago. To me, the exceptional thing which the Reason project lacks is a polished developer experience. It feels very much like a hacked together combination of technologies which requires the developer to install several things just to get a working compiler. I think before I would try Reason again there would need to be some effort put into streamlining setup and managing of the developer environment. EDIT: Downvoted? Let's hear some feedback and other opinions maybe?

quicksnap 9y ago
There has been a lot of work in making the developer experience as awesome as possible. I know that, for the core team, it is one of the highest priorities. While this tutorial doesn't use the official bootstrap, you can see it here: https://facebook.github.io/reason/gettingStarted.html https://facebook.github.io/reason/gettingStarted.html -- It's only a few lines in your terminal! The integration with VSCode is pretty amazing, too.
mambodog 9y ago
At this stage, the only thing you need to do to get Reason to 'work' is to use Create Reason React App (when targeting the browser). The language/compiler itself is installed as an npm package(!). The only other things to install are the CLI tools (again, just an 'npm install' away) and optionally a plugin for your editor.

megamindbrian 9y ago

For what reason do we need yet another dialect of JavaScript?

modarts 9y ago
It's not a dialect of JavaScript, but rather a typed, compile to js language.
girvo 9y ago
It's a "dialect" (sort of) of Ocaml, with all of the beauty that is its type system and Functor (not thing.map, parameterized modules!) that can compile to JavaScript via Bucklescript.

jaequery 9y ago

this might be the tipping point of js fatigue for most React/JS developers. we can only hope this doesn't catch on, fingers crossed.

TheAceOfHearts 9y ago
If it's ends up being notably superior in multiple ways, and you already have a properly configured and flexible build toolchain in place (i.e. Webpack), adding support should be trivial. I haven't personally used it, but a quick search landed me on the bs-loader [0] repo, which claims to work with both OCaml and Reason files. As I understand it, and I'm not very familiarized with Reason, the team behind the project is working hard to have a good interop story. We've seen the same thing with React's versioning scheme [1]! Going forward there shouldn't be horrible breaking changes, and in the cases where stuff must be broken, they appear to commit to providing a clear migration path that can be adopted gradually. There's probably plenty of good use-cases for using something like Reason. Should it be used everywhere? No, certainly not. But having worked on a reasonably sized JavaScript web app, my experience has been that it becomes increasingly difficult to maintain as it grows. Even with something like Flow or TypeScript, you have to think very carefully any changes. Luckily, the JavaScript ecosystem has modularized everything quite heavily, so you can usually contain things that end up being "bad ideas" and gradually chip away at em. The app I worked on wasn't even that large or complicated, so I have a very hard time wrapping my head around the challenges faced by engineers working on Facebook's scale. [0] https://github.com/rrdelaney/bs-loader https://github.com/rrdelaney/bs-loader [1] https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html https://facebook.github.io/react/blog/2016/02/19/new-version...

crucialfelix 9y ago

There is an online ocaml to js converter here: http://bucklescript.github.io/bucklescript/js-demo/index.html http://bucklescript.github.io/bucklescript/js-demo/index.htm...

IX_Hispana 9y ago

This, not unlike Elm, looks pristine, ivory-tower-ish to me. The examples are always neatly self-contained or consuming a real simple json API. They're fiddles. Fiddles always look neat. I think it would do these types of projects a lot of good to do something real using third party libraries. Convince developers and companies they're real, not toys. I still haven't seen a blog post explaining Elm along with a masonry library, socket.io, bootstrap, shopify, etc. Probably I'm not getting what's the real use case for these things. It can't be writing web apps.

mambodog 9y ago
I don't think Reason is like Elm in this way. Whereas Elm requires you to wholly buy in to the Elm world, Reason can easily be brought into a large existing codebase. Large chunks of messenger.com are written in Reason. I'm pretty sure that qualifies as a 'web app'.
- IX_Hispana 9y ago
  Hey, thanks for the reply. What would you say is a good opportunity in a project to sneak some Reason in?