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).
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].
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
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