6 ms·

Honest question: why would someone use this instead of React? From my point of view, React solved a real problem. JS before React (at least old-skool, with jQu

by amenod 8y ago

Honest question: why would someone use this instead of React? From my point of view, React solved a real problem. JS before React (at least old-skool, with jQuery & co.) was simply unmaintainable. It was often easier to thow old projects away and start anew than to maintain what inevitably became a tangled mess of callbacks and global variables. Not because of incompetency of developers (at least I hope so ;) but because there were no standard of encapsulation, separation of concerns and similar. Why would someone who knows React want to switch to ReasonML?

ch4s3 8y ago
For the same/similar reasons, more or less. You get a great type system, merlin(a great analysis tool), faster compilation, all kinds of great compile time checks, and you can still use react.
- mLuby 8y ago
  Those are all good things, but they aren't really the same reason. Parent describes JQuery to React as spaghetti code -> reasonable code, whereas React to ReasonML sounds like reasonable code -> reasonable code (with better tooling).
  - ch4s3 8y ago
    Yeah, I agree but would say reasonable code -> slightly more maintainable, reasonable code. Sure, the low hanging fruit is gone, but it's a similar reason. What I'm getting at is that you can write spaghetti React pretty easily, and people do. One of the core promises of using an ML to do react is that its harder to mess with state all over the app and wind up with a big bowl of spaghetti.
  - cies 8y ago
    JS code can be a pain to maintain (in the membrane... joke, sorry, I'll stop). And FB knows this. That's why they developed ReasonML: great JS interop, but much better maintenance story (than both JS and TS) because of the stronger typing discipline. On a large code base, increased maintainability can be a huge commercial advantage.
hellofunk 8y ago
Because React is a very natural fit for a functional language of which JS really isn’t. Which is also why it is so lovely to use React from Clojurescript.
- Scarbutt 8y ago
  How's Clojurescript interop story? what always holds me from using these compile to JS langs is the fear that the gains you get from using a better/nicer language are completely destroyed by all the interop churn.
  - lilactown 8y ago
    As someone who's done a bunch of interop in ReasonML & ClojureScript, ClojureScript interop blows ReasonML away (in terms of ease) at the language level. The current problem with ClojureScript interop is the Google Closure compiler's support for stuff on npm. I switched our team to using shadow-cljs[0] and it solved all of those problems. Would highly recommend. [0] http://shadow-cljs.org/ http://shadow-cljs.org/
    - hajile 8y ago
      What level of inter-opt? If you want to gradually convert from JS to clojurescript, it seemed like a huge amount of work.
      - lilactown 8y ago
        Ah, hmm. Using JS from CLJS is incredibly easy. Like I said, shadow-cljs solved all of our problems there. Going the other way - using code written in CLJS in JS - is another matter. This is not well supported by the ecosystem. shadow-cljs has much, much better support for this than the standard ClojureScript/closure compiler, but it doesn't hold a candle to what BuckleScript does. IME, doing a top-down transition - where you convert the top of your app to ClojureScript, that calls everything - works best. From the top, you work your way down into each feature. ReasonML, on the other hand, works better from the bottom up. Typing your whole app is hard, so you start with some small feature that then you export to JS land (since that's so much easier with BuckleScript). From the bottom, you work your way into writing more and more features in ReasonML.
yashafromrussia 8y ago
Someone who knows React can easily be using ReasonML. So to me, the question is, why not? You can get most of the features of ReasonML with 3rd party libs - TypeScript for type safety, Redux for state management, and Immutable. However, when I look at the build time comparison, I doubt you'd get something as fast with JavaScript, at least not today.
- actsasbuffoon 8y ago
  Typescript, Redux, and Immutable.js work together as a pretty compelling stack, but they involve a fair bit of boilerplate compared to Elm or ReasonML. Elm provides type safety, immutable data structures, and state management in a very compact but readable way. In fact, Redux was strongly inspired by Elm's state management. All of these stacks are perfectly acceptable choices, so it comes down to a matter of personal preference. I'd encourage everyone to spend some time with Elm and ReasonML. I find them to be productive and very enjoyable tools.
  - cies 8y ago
    > compared to Elm or ReasonML PureScript deserves a mention in this list as well. More full-featured and general purpose than Elm, cleaner design than ReasonML. Prolly the smallest community of the 3.
    - actsasbuffoon 8y ago
      I love Purescript, but I'd be hesitant to recommend it to anyone without a Haskell background. There's a lot more to learn in Purescript, and I'd worry that it could discourage people who are new to the Haskell family of languages. I'd advise starting with Elm to fall in love with the development experience and wonderful error messages, and graduating to Purescript when you need more power.
    - christophilus 8y ago
      I like PureScript a whole lot. Something that ClojureScript and Reason seem to have on PureScript is really efficient persistent structures being the default, at least if I remember correctly. It's been a while, but I seem to recall PureScript giving me nice, functional syntax that under the hood did lots of native JS object / array copies.
Scarbutt 8y ago
Some developers believe (and prefer) in that good type systems help for large software projects.
- cies 8y ago
  A company like FB believes so too, judging from how much resources they throw at it.
ardfard 8y ago
ReasonML is a language that transpiles to JS, not a view library so it's not gonna replace React. The more appropriate question is why someone use this for developing React app rather than using plain JS? The answer is IMO because React paradigm lent itself better with functional way of handling state like immutability and persistent data structures that's why ReasonML is more like a perfect match.
bratsche 8y ago
You wouldn't necessarily use ReasonML instead of React, you can use them together. You would use ReasonML instead of whatever Babel/es6/es7/typescript/whatever. Here is the official React binding (or whatever you call it) for ReasonML: https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/ Using this you would still be using React, just in a different language. But my understanding is that you would not be using redux (if you are now) because it doesn't make sense in a language like ReasonML.
- RussianCow 8y ago
  > But my understanding is that you would not be using redux (if you are now) because it doesn't make sense in a language like ReasonML. Why would using Redux not make sense? It's not like the problem of sharing state between components goes away with a functional language?
  - Kiro 8y ago
    It's covered in the article: "When using ReasonML, we don't need Redux anymore. ReactReason stateless components already come with the concept of a build in reducer, which is meant to take care of the problems Redux used to address."
    - RussianCow 8y ago
      Reducers are only one (and IMO the least important) part of using Redux with React; the other part is `connect`, which lets you pass global state directly into a deeply nested component without passing it all the way down the tree via props. Unless I'm mistaken, ReactReason doesn't offer an alternative to that.
      - cdaringe 8y ago
        Historically a single connected root has been frowned upon. I'm not so sure it should still be feared now that you can use PureComponents and FSCs the whole way down. ShouldComponentUpdate calls are cheap in pure-town.
simplify 8y ago
ReasonML has more potential. Aside from its excellent type system (one of the best), it can also compile to native code. This has several benefits: - Frontend: Your tools are fast. The ReasonML-to-JS compiler is already an order of magnitude faster that TypeScript, etc. Fastpack is a native bundler in the works that aims to bundle your project in under a second (and faster for incremental builds). - Mobile & Desktop: Some are experimenting right now with writing a version of React in pure Reason that compiles to native code, bypassing the JavaScript runtime entirely. - Backend: You'll be able to use the Node.js ecosystem but compile certain modules to native code when you need critical performance. Edit: I should add, the Node.js backend story is currently the least developed part of the ecosystem (I'm personally working on getting that up to speed).
- amenod 8y ago
  Thanks (to the others too), that does sound good.
- komuW 8y ago
  This reminds me that all those points would apply to dartlang
  - cookiecavekeep 8y ago
    Except for the speed argument. For AngularDart projects: the current compiler (ddc) takes minutes to warm up and since it keeps all assets in memory, is quite memory hungry as well. The new incremental build tools are much nicer to use (store assets on disk), and a lot faster after the first build, but still nowhere near sub-second.
- christophilus 8y ago
  Yeah. The OCaml compiler is just crazy fast. It's like Go, but with a super nice functional language. The compiler seems to be doing a heck of a lot of heavy-lifting in such a small amount of time. I'd be interested in a talk about how it manages that, if anyone knows of one.
  - 8y ago
scns 8y ago
Facebook rewrote Messenger in Reason. Before they had hundreds of bugreports in a year. Afterwards? Less then ten.
- Scarbutt 8y ago
  Is there some official analysis of this?
  - adamkl 8y ago
    Note, the ReasonML rewrite refers to the Web version of Messenger only (at the time of this blog post): https://reasonml.github.io/blog/2017/09/08/messenger-50-reason.html https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...
  - tigershark 8y ago
    Everyone that works with F# and OCAML can confirm the trend I guess..
- cjbprime 8y ago
  Did they rewrite it using the old language too, as a control? :)
Rotareti 8y ago
The last ReactJS project I was working on ended up with libraries such as Ramda, ImmubtableJS, recompose, etc, in order to make the codebase more functional... We also switched to TypeScript for the type-system. While these libs improved the overall experience, it never came close to what you get from a proper functional language. I'm currently working on a frontend that uses ReasonReact and it feels much smoother. > Honest question: why would someone use this instead of React? The libraries I mentioned have __a_lot__ of stars on github, I'm sure many people using them, those might be better off with ReasonML. I hope ReasonML will succeed and the ecosystem catches up. ReasonML is the fucntional general purpose language I always wanted. If they get the concurrency story right it might become a nice functional alternative to Golang as well.
- dmead 8y ago
  fucntional
crimsonalucard 8y ago
Nobody mentioned the biggest reason. True functional programming coupled with type checking leads to more modular programs with significantly less bugs. I don't know about ReasonML, but a similar framework called ELM delivers Zero run time errors. Zero. Languages that eliminate entire classes of errors from type errors to run time errors should be the future evolution of programming languages. React+redux was only a small step in the right direction.
- disease 8y ago
  Well said. When we went from JavaScript to TypeScript we completely eliminated any errors we had associated with types. Then we turned on the noImplicitAny and strickNullChecks options and completely got rid of our 'x is not a function of y' and 'z is not defined' errors.
gildas 8y ago
> From my point of view, React solved a real problem. JS before React (at least old-skool, with jQuery & co.) was simply unmaintainable Why would someone who knows Dojo or GWT want to switch to React?

by amenod 8y ago

ch4s3 8y ago

For the same/similar reasons, more or less. You get a great type system, merlin(a great analysis tool), faster compilation, all kinds of great compile time checks, and you can still use react.

mLuby 8y ago
Those are all good things, but they aren't really the same reason. Parent describes JQuery to React as spaghetti code -> reasonable code, whereas React to ReasonML sounds like reasonable code -> reasonable code (with better tooling).
- ch4s3 8y ago
  Yeah, I agree but would say reasonable code -> slightly more maintainable, reasonable code. Sure, the low hanging fruit is gone, but it's a similar reason. What I'm getting at is that you can write spaghetti React pretty easily, and people do. One of the core promises of using an ML to do react is that its harder to mess with state all over the app and wind up with a big bowl of spaghetti.
- cies 8y ago
  JS code can be a pain to maintain (in the membrane... joke, sorry, I'll stop). And FB knows this. That's why they developed ReasonML: great JS interop, but much better maintenance story (than both JS and TS) because of the stronger typing discipline. On a large code base, increased maintainability can be a huge commercial advantage.

hellofunk 8y ago

Because React is a very natural fit for a functional language of which JS really isn’t. Which is also why it is so lovely to use React from Clojurescript.

Scarbutt 8y ago
How's Clojurescript interop story? what always holds me from using these compile to JS langs is the fear that the gains you get from using a better/nicer language are completely destroyed by all the interop churn.
- lilactown 8y ago
  As someone who's done a bunch of interop in ReasonML & ClojureScript, ClojureScript interop blows ReasonML away (in terms of ease) at the language level. The current problem with ClojureScript interop is the Google Closure compiler's support for stuff on npm. I switched our team to using shadow-cljs[0] and it solved all of those problems. Would highly recommend. [0] http://shadow-cljs.org/ http://shadow-cljs.org/
  - hajile 8y ago
    What level of inter-opt? If you want to gradually convert from JS to clojurescript, it seemed like a huge amount of work.
    - lilactown 8y ago
      Ah, hmm. Using JS from CLJS is incredibly easy. Like I said, shadow-cljs solved all of our problems there. Going the other way - using code written in CLJS in JS - is another matter. This is not well supported by the ecosystem. shadow-cljs has much, much better support for this than the standard ClojureScript/closure compiler, but it doesn't hold a candle to what BuckleScript does. IME, doing a top-down transition - where you convert the top of your app to ClojureScript, that calls everything - works best. From the top, you work your way down into each feature. ReasonML, on the other hand, works better from the bottom up. Typing your whole app is hard, so you start with some small feature that then you export to JS land (since that's so much easier with BuckleScript). From the bottom, you work your way into writing more and more features in ReasonML.

yashafromrussia 8y ago

Someone who knows React can easily be using ReasonML. So to me, the question is, why not? You can get most of the features of ReasonML with 3rd party libs - TypeScript for type safety, Redux for state management, and Immutable. However, when I look at the build time comparison, I doubt you'd get something as fast with JavaScript, at least not today.

actsasbuffoon 8y ago
Typescript, Redux, and Immutable.js work together as a pretty compelling stack, but they involve a fair bit of boilerplate compared to Elm or ReasonML. Elm provides type safety, immutable data structures, and state management in a very compact but readable way. In fact, Redux was strongly inspired by Elm's state management. All of these stacks are perfectly acceptable choices, so it comes down to a matter of personal preference. I'd encourage everyone to spend some time with Elm and ReasonML. I find them to be productive and very enjoyable tools.
- cies 8y ago
  > compared to Elm or ReasonML PureScript deserves a mention in this list as well. More full-featured and general purpose than Elm, cleaner design than ReasonML. Prolly the smallest community of the 3.
  - actsasbuffoon 8y ago
    I love Purescript, but I'd be hesitant to recommend it to anyone without a Haskell background. There's a lot more to learn in Purescript, and I'd worry that it could discourage people who are new to the Haskell family of languages. I'd advise starting with Elm to fall in love with the development experience and wonderful error messages, and graduating to Purescript when you need more power.
  - christophilus 8y ago
    I like PureScript a whole lot. Something that ClojureScript and Reason seem to have on PureScript is really efficient persistent structures being the default, at least if I remember correctly. It's been a while, but I seem to recall PureScript giving me nice, functional syntax that under the hood did lots of native JS object / array copies.

Scarbutt 8y ago

Some developers believe (and prefer) in that good type systems help for large software projects.

cies 8y ago
A company like FB believes so too, judging from how much resources they throw at it.

ardfard 8y ago

ReasonML is a language that transpiles to JS, not a view library so it's not gonna replace React. The more appropriate question is why someone use this for developing React app rather than using plain JS? The answer is IMO because React paradigm lent itself better with functional way of handling state like immutability and persistent data structures that's why ReasonML is more like a perfect match.

bratsche 8y ago

You wouldn't necessarily use ReasonML instead of React, you can use them together. You would use ReasonML instead of whatever Babel/es6/es7/typescript/whatever. Here is the official React binding (or whatever you call it) for ReasonML: https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/ Using this you would still be using React, just in a different language. But my understanding is that you would not be using redux (if you are now) because it doesn't make sense in a language like ReasonML.

RussianCow 8y ago
> But my understanding is that you would not be using redux (if you are now) because it doesn't make sense in a language like ReasonML. Why would using Redux not make sense? It's not like the problem of sharing state between components goes away with a functional language?
- Kiro 8y ago
  It's covered in the article: "When using ReasonML, we don't need Redux anymore. ReactReason stateless components already come with the concept of a build in reducer, which is meant to take care of the problems Redux used to address."
  - RussianCow 8y ago
    Reducers are only one (and IMO the least important) part of using Redux with React; the other part is `connect`, which lets you pass global state directly into a deeply nested component without passing it all the way down the tree via props. Unless I'm mistaken, ReactReason doesn't offer an alternative to that.
    - cdaringe 8y ago
      Historically a single connected root has been frowned upon. I'm not so sure it should still be feared now that you can use PureComponents and FSCs the whole way down. ShouldComponentUpdate calls are cheap in pure-town.

simplify 8y ago

ReasonML has more potential. Aside from its excellent type system (one of the best), it can also compile to native code. This has several benefits: - Frontend: Your tools are fast. The ReasonML-to-JS compiler is already an order of magnitude faster that TypeScript, etc. Fastpack is a native bundler in the works that aims to bundle your project in under a second (and faster for incremental builds). - Mobile & Desktop: Some are experimenting right now with writing a version of React in pure Reason that compiles to native code, bypassing the JavaScript runtime entirely. - Backend: You'll be able to use the Node.js ecosystem but compile certain modules to native code when you need critical performance. Edit: I should add, the Node.js backend story is currently the least developed part of the ecosystem (I'm personally working on getting that up to speed).

amenod 8y ago
Thanks (to the others too), that does sound good.
komuW 8y ago
This reminds me that all those points would apply to dartlang
- cookiecavekeep 8y ago
  Except for the speed argument. For AngularDart projects: the current compiler (ddc) takes minutes to warm up and since it keeps all assets in memory, is quite memory hungry as well. The new incremental build tools are much nicer to use (store assets on disk), and a lot faster after the first build, but still nowhere near sub-second.
christophilus 8y ago
Yeah. The OCaml compiler is just crazy fast. It's like Go, but with a super nice functional language. The compiler seems to be doing a heck of a lot of heavy-lifting in such a small amount of time. I'd be interested in a talk about how it manages that, if anyone knows of one.
- 8y ago

scns 8y ago

Facebook rewrote Messenger in Reason. Before they had hundreds of bugreports in a year. Afterwards? Less then ten.

Scarbutt 8y ago
Is there some official analysis of this?
- adamkl 8y ago
  Note, the ReasonML rewrite refers to the Web version of Messenger only (at the time of this blog post): https://reasonml.github.io/blog/2017/09/08/messenger-50-reason.html https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...
- tigershark 8y ago
  Everyone that works with F# and OCAML can confirm the trend I guess..
cjbprime 8y ago
Did they rewrite it using the old language too, as a control? :)

Rotareti 8y ago

The last ReactJS project I was working on ended up with libraries such as Ramda, ImmubtableJS, recompose, etc, in order to make the codebase more functional... We also switched to TypeScript for the type-system. While these libs improved the overall experience, it never came close to what you get from a proper functional language. I'm currently working on a frontend that uses ReasonReact and it feels much smoother. > Honest question: why would someone use this instead of React? The libraries I mentioned have __a_lot__ of stars on github, I'm sure many people using them, those might be better off with ReasonML. I hope ReasonML will succeed and the ecosystem catches up. ReasonML is the fucntional general purpose language I always wanted. If they get the concurrency story right it might become a nice functional alternative to Golang as well.

dmead 8y ago
fucntional

crimsonalucard 8y ago

Nobody mentioned the biggest reason. True functional programming coupled with type checking leads to more modular programs with significantly less bugs. I don't know about ReasonML, but a similar framework called ELM delivers Zero run time errors. Zero. Languages that eliminate entire classes of errors from type errors to run time errors should be the future evolution of programming languages. React+redux was only a small step in the right direction.

disease 8y ago
Well said. When we went from JavaScript to TypeScript we completely eliminated any errors we had associated with types. Then we turned on the noImplicitAny and strickNullChecks options and completely got rid of our 'x is not a function of y' and 'z is not defined' errors.

gildas 8y ago

> From my point of view, React solved a real problem. JS before React (at least old-skool, with jQuery & co.) was simply unmaintainable Why would someone who knows Dojo or GWT want to switch to React?