bryanphe

> However, I really don't like the fact that there is no way to navigate tabs using vim's commands.

I created an Electron (TypeScript/React) desktop application called Onivim [1] and then re-built it for a v2 in OCaml / ReasonML [2] - compiled to native machine code. (And we built a UI/Application framework called Revery [3] to support it)

There were very significant, tangible improvements in performance:

- Order of magnitude improvement in startup time (time to interactive, Windows 10, warm start: from 5s -> 0.5s)

- Less memory usage (from ~180MB to <50MB). And 50MB still seems too high!

The tooling for building cross-platform apps on this tech is still raw & a work-in-progress - but I believe there is much untapped potential in taking the 'React' idea and applying it to a functional, compile-to-native language like ReasonML/OCaml for building UI applications. Performance is one obvious dimension; but we also get benefits in terms of correctness - for example, compile-time validation of the 'rules of hooks'.

We're working on a framework that address 1, 2, 2.1, 3, and 3.1 - Revery [0] - a React-like framework that compiles to native code, built with ReasonML [1]. I believe that the React pure-functional model of UI-as-a-function-of-state is such a powerful paradigm, and not leveraged on native today - ReasonML is a perfect fit for that.

Bullet point 4 is a non-goal for Revery, but our sister project, Brisk [2] is built on platform widgets.

I'd personally also add a couple of dev experience bullet points or ideas to the "holy grail":

6) Fast / instant compilation time

7) Hot-reload (see changes to the app instantly)

We're not there yet, but we hope we could also get to the point of including 6/7 - essentially bringing some of the great aspects of React/Redux to desktop application development, with native code.

- Native code - does the GUI framework compile to machine code?

- Native widgets - does the GUI framework use platform widgets, or a platform agnostic layer?

In the context of Revery, we used "native" to mean "native code", ie, "compiles to machine code" - and further clarify in the README. It's important for us to make this differentiation - because often people look at the framework and assume its JavaScript.

Do you have a suggestion on how to clarify this?

GLFW takes a lot of the pain out of cross-platform GPU development, and I've found the API simple and intuitive to work with. For those looking to play with it - the LearnOpenGL tutorial series [2] is excellent, and uses GLFW for managing a window and getting an OpenGL context.

Thank you maintainers for your work on it!

> It does seem to exhibit the usual custom rendered app issues. I suppose it is constantly redrawing the screen, as it seems to have constant cpu usage even when doing nothing, so not laptop friendly (though perhaps fixable still).

Yes, at least when there is an animation active (we redraw the screen in that case). Most event-based apps, though, would only redraw in response to user input or for a temporary animation - our initial demo is constantly animating at 60hz, so maybe not the best performance demo...

> Some of the widget seem fairly arcane but usable.

Definitely. Still a lot of work needed here. We've had some excellent help from the community getting an initial palette of controls; but still a ways to go!

> One thing that was very alien to me was the build tooling and language/runtime.

This is great feedback. We should include more details in our README about this. The stack is really Esy [1] -> Dune [2] -> OCaml compiler (ocamlopt) [3]. Then C linker for your platform.

> Also how easy would it be to link C/Rust lib, so that revery would only be used as the UI layer for something else.

I haven't tried Rust, but C libs are doable with Reason/OCaml's C FFI [1]. In fact, several of the underlying pieces of technology powering Revery (GLFW, FreeType2, Harfbuzz) are used via this FFI [4].

I apologize that there isn't more info - we're still working on website, docs, architecture diagrams, etc. But I'll be around for a bit to answer questions. It's still pretty new and actively developed - we're building it in parallel with the next version of our Oni [1] text editor. Some of the rationale for this decision can be found in our early architecture document for the next version of Oni [2].

ReasonML (which is a syntax over OCaml) is now a great environment to build native apps. Most of the attention has been focused on the compile-to-JS scenarios, but the tooling is at the point where you can just as easily compile-to-native on the major platforms, thanks to tools like Esy [3] - workflow isn't much different from NPM+JS development!

Jordan and team, as well as OCamlLabs on the OCaml side, have been smoothing out this native workflow (it's not easy to build a package manager for native code!), and I think/hope you'll see more ReasonML projects like Revery start to pop-up.

I'm bullish on this because React-as-a-paradigm (pure-functional UI) is a natural fit - it's like a language designed for React.

Not only that, there is some incredible work that has been invested in the OCaml ecosystem, too:

- The compiler is FAST

- The GC is FAST (also deterministic and supports sliced collections, important for perf)

- Very powerful type system (ADTs, GADTs) - we even express the React 'rules of hooks' in types, such that they're enforced in the compiler.

The output code generated by the OCaml compiler (ocamlopt) is fast too - in some cases on par with C++ [4]

Everything seemed to line up in terms of tech to make it a natural fit for us to give it a try :)

And Revery is meant for very custom UIs - there is a counterpart project called Brisk [5] that uses platform-native widgets. We share common infrastructure and in fact uses Brisk's reconciler to provide the 'React' layer and component model.

I've been continually amazed at the ingenuity of the React ecosystem - so many intricate, well-designed custom controls - I believe if you have the write set of primitives, that community can make amazing things happen. So I'm hopeful and optimistic that we can at least get a subset of decent controls. But agree it's a challenge!

There are some cases (like text input) that are just so hard to get right - and can even change between OS versions - so we're looking at native support for some of those pieces.

Also, there is another project, similar in spirit to Revery, called Brisk [1] that uses platform-native widgets entirely. We're actually working closely together with them.