boyswan

reasonml <3

I'm only guessing that's because you have prior experience with Ember and are only starting to use react now.

I find code written in ReasonML is 100x more maintainable than anything written in javascript, whether it's react or ember

Similar to flow. JS interop is great, so you can literally change bit by bit and refactor from the inside out.

Also for your issue with deeply nested options, have a look at this

https://medium.com/w3reality/working-with-option-using-maybe...

Since moving from javascript to reason/ocaml, i'm genuinely nervous about refactoring Js now. Helpful compiler errors are literally life changing, and being able to handle options with Some/None means no more nasty undefined bugs.

You can do a lot of funky things with javascript, and it's easy to convince yourself that because you can do it, you should do it. With reason I've found I can achieve pretty much anything with a far more concise set of tools, and I can't hack my way around problems - I'm forced to deal with them the correct way.

Being forced to do things in a certain way has a massive benefit, and encourages consistency. You can look at 5 different javascript projects and each one of them will most likely be completely different.

You forgot the best bit... variants and pattern matching!

I thought this and was put off at first, but have come to the conclusion that you really don't need redux (I've used it thoroughly for years).

We've been converting a large JS react app to Reason, and strongly typed props solves a lot of problems. Passing props down multiple children is no longer a burden, and you'll never have that "prop spreading madness". For anything that reaaally requires some sort of global state, you can use the new react context api.

The only danger of writing in reasonml is spoiling javascript for yourself