ohadrau

Years ago when I was around 14, I stumbled upon Chris's Katahdin project and thought it was such a cool idea I had to try it out. I spent quite a bit of time trying to get set up with it, and not knowing much about C# couldn't really figure it out myself. I ended up reaching out to Chris before giving up on it, not expecting much. To my surprise, Chris spent several hours helping me out and answering my (probably very dumb) questions. I was shocked at how helpful and welcoming he was. Despite the relatively brief encounter I can easily say Chris was one of the kindest programmers I've had the pleasure of interacting with.

It's hard for me to express how much this title hit me when I read it. Like many in this thread, Chris had an enormous impact on my path as a programmer and I'm quite sad that I never got the chance to properly thank him. RIP, Chris

Just to clarify to people not familiar with the two languages and their differences, this is somewhere where the two languages diverge greatly. OCaml does not have an "obj" type that we can cast to (and in general casts are quite rare).

While the object system is pretty rarely used [1], polymorphic variants see quite a bit of use and are also based on row types.

[1] Recently have been seeing a lot more use in BuckleScript because of the JS object representation

Not entirely. For now Flutter is focused mainly on mobile apps whereas Revery is focused primarily on desktop apps (though we do plan to tackle mobile apps eventually and Google is sort of moving in the direction of targeting desktop in Flutter).

However, we are like Flutter in that we're implementing all the UI components from scratch. It is a lot of work but I've been shocked by how quickly things have moved -- I made my first PR a little over a month ago and since then we've gotten: checkboxes, sliders, scrolling, buttons, input components, box shadows, overflows, etc. as well as a ton of performance/bug fixes. Our example apps went from rendering images to including an interactive version of Conway's Game of Life seemingly overnight.

Looks like this is using Fluid rather than Revery. Not sure about memory usage in Revery but I think it should be lower than that. Definitely something I'll look into

Unfortunately, we aren't compiling pure React code to native -- for something like that Electron is probably the go-to solution for now. However, the reverse is true. Revery apps can be compiled into a web app without you needing to do anything (assuming you aren't using any native-only libraries with it). So all our example code is automatically able to be compiled to a JS web app.

Sorry this just hasn't been updated in a few weeks. I just opened a PR to update the README to clarify that. We actually have all of those done right now. Here's a gif of radio buttons in action from a pull request [1].

[1] https://user-images.githubusercontent.com/21044999/51702694-...

To be fair, issues with bindings have really not been too common and when they appear the fix is just opting out of the strong type checking. 9 times out of 10 when we have a bug the issue is actually something not specific to Reason, like Webpack making 2 copies of React in the output,

For me, Reason's type system seems a lot more focused on what it's trying to do. It's much more minimal than TypeScript's, so you don't end up trying to hack it to fit weird JS types. This also means you get full type inference which is huge.

The other nice things are the fact that it's not backwards compatible with JS so a lot of the syntax is a little more convenient and the module system + object system are the same really powerful ones that OCaml has. Plus, the entire paradigm of the language is so different that it totally changes the way you use React (I remember having all kinds of issues my first time trying to use React just because of how weird some functional stuff is to do in JS, whereas in Reason virtually any program that typechecks is 100% valid for React).

I know this is getting downvoted a ton, but I certainly felt the same way before using Reason. Even now, I'm sort of undecided about my opinion on it. I love how accessible it makes OCaml (which I think it does, people pay more attention to syntax than they really ought to) but I'm always afraid that it's going to cause native OCaml to be abandoned. Reason can also sometimes make code needlessly complex IMO because it hides some of the really clear aspects of OCaml's syntax. That said, it's improved a ton since it was first released and no longer feels like a weird soup of mixed up languages.

Even then, I feel like working with Floats vs. Ints in a web browser is almost never an issue. I'd just open Float if I need it because I can't think of any scenario where I'd use both in one module

Like a ton of other people here, we've been using ReasonML for about half a year now at Rolltrax [1] and so far I can say I'm ~95% happy with it. I'm a long-time OCaml user but my co-founder had 0 experience in OCaml when we decided to make the switch to Reason. I'll just list off some things we've found using Reason so far:

Positives:

* Really quick to get productive -- the syntax really does do a great job getting new users familiar with the language constructs (I was very skeptical about this before)

* ReasonReact is very nice and works great out of the box

* Writing bindings is generally pretty easy to do, and we're currently maintaining 4 of these (+ 2 existing binding we've contributed to)

* The language and compiler do a great job at working with you to figure out issues

* Everything feels a million times more structured than normal JS code

* Not sure if this is an up-side, but writing code in Reason is so much smoother than other languages that I feel like it's pushed us to implement more client-side features than server-side ones (unfortunately, this means everything depends on a ton of JS)

* Super readable, I feel like I can skim the code and know exactly what it does instantly

Negatives:

* It's still JS, which means you have to deal with a ton of crap from NPM, WebPack, JS's module system, weirdly written libraries that don't do well with bindings, and things breaking in weird ass ways that you can't easily debug... I think this has been the source of 90% of our bugs so far

* Still no way of getting higher-order components working well, specifically with bindings, which makes it really hard to work with libraries like react-grid-layout

* Polymorphism could still be improved. We occasionally get type signatures that should work in theory but can't because of the object system's limitations, which means we have to give up on the type safety and fiddle with Obj.magic or external JS code

* The JSX syntax is still annoying because you can't use spread syntax with a native element (e.g. div), although eventually I'm gonna get tired enough of doing that that I'll open a PR to fix it

Overall, Reason is by far my favorite way of writing web apps. If that's something you've got to do, give Reason a try. There's still a few pain points but interop with JS is so simple that it hasn't really slowed us down (except when webpack breaks lol)