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

There's a related feature request here: https://github.com/onivim/oni2/issues/3673

> I also find the VSCode similarities distracting and it seems to be causing confusion to would be investors of this due to the assumption it's some branch of it as opposed to a completely new editor.

I agree, this is consistent feedback we get... There's a ton of potential to have a built-for-modal-editing UX that we're missing at the moment.

> Finally, is there a way to remove the system bar on the top in the configuration? I can toggle most elements of the UI but that system bar is visible even in zen mode and I never use it in any text editor with support for keyboard driven commands.

Yes, there is a `window.menuBarVisibility` configuration setting: https://onivim.github.io/docs/configuration/settings#layout

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'.

- [1] Onivim v1 (Electron) https://github.com/onivim/oni

- [2] Onivim v2 (ReasonML/OCaml) https://v2.onivim.io

- [3] Revery: https://www.outrunlabs.com/revery/

- [4] Flambda: https://caml.inria.fr/pub/docs/manual-ocaml/flambda.html

See VSCode, Discord, Spotify...

It's easier to get a single code-base that 'just works' across platforms if you have an abstraction that is truly cross-platform. One of the major value propositions of developing with Electron is this ability to develop cross-platform 'with confidence' - I can build an app on Windows and be 99% sure it's going to look function the same on OSX / Linux.

> I want my macOS apps to use Mac-native UI elements, and Windows apps to use Windows-native UI elements

That's a fine goal but it means you end up needing more platform-specific code. It's a trade-off, and there isn't a one-size-fits-all solution.

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.

- [0] Revery: https://github.com/revery-ui/revery

- [1] ReasonML: https://reasonml.github.io/

- [2] Brisk: https://github.com/briskml/brisk

- 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?

Note that, if you're interested in using the platform UI - there's a project called Brisk (https://github.com/briskml/brisk) that is very similar to Revery, but uses platform UI frameworks (Cocoa/Win32/etc).

Would like to have image-based verification for certain classes of tests, and we use Azure CI pipelines - seems their VMs don't have hardware support at all for OpenGL (on any platform).

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!

- [1] Revery: https://github.com/revery-ui/revery

- [2] LearnOpenGL: https://learnopengl.com/Getting-started/Creating-a-window

- A package manager like NPM, but for native code: https://github.com/esy/esy

- A fast Node version manager: https://github.com/Schniz/fnm

- A fast replacement for dotenv-cli: https://github.com/ulrikstrid/reenv

- A fast JS bundler: https://github.com/fastpack/fastpack

- A native language server: https://github.com/jaredly/reason-language-server

The OCaml language and toolchain is very powerful... and I do believe ReasonML makes it more approachable, at least for a wider audience of developers comfortable with JavaScript-style syntax.

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

[1] https://esy.sh/

[2] https://dune.readthedocs.io/en/latest/quick-start.html

[3] https://caml.inria.fr/pub/docs/manual-ocaml/native.html

[4] https://github.com/bryphe/reason-glfw

We really just want a license that says - free to use for educational / non-commercial purposes, but a license is required to use in a commercial environment. No real "drop-in" licenses to support this, unfortunately. Some additional thoughts about our considerations here: https://www.reddit.com/r/neovim/comments/ae7ef6/question_abo...

The work that we want to share out (custom widgets that are more generally applicable) will live in Revery - that's the reason we split Revery out from Oni2 into an MIT Licensed project - so that we could share the heart of the work out with a broader community, and get help building out this foundation, too.

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.

[1] https://github.com/onivim/oni

[2] https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a...

[3] https://esy.sh/

[4] http://www.ffconsultancy.com/languages/ray_tracer/comparison...

[5] https://github.com/briskml/brisk

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.

[1] https://github.com/briskml/brisk

I agree 100% that it isn't always the proper trade-off, though - there's another ReasonML project called Brisk [1] that is similar in spirit to Revery, but with platform widgets.

In fact, we're working together on several infrastructure pieces (the core 'reconciler' - the native React-like piece - is actually developed by the Brisk team). So if you're interested in ReasonML + native app development - that might be one to follow!

We see the potential too for some exciting hybrid approaches - perhaps you prototype a cross-platform app in Revery, but then switch to Brisk for platform-specific projects, etc. Or even embed Revery in Brisk.

[1] https://github.com/briskml/brisk

I've been using for developing native projects with ReasonML / OCaml (on Windows!) - a framework called Revery [1] (a fast, native alternative to Electron) and a re-write for our Oni [2] text editor using this platform. It really wouldn't have been possible to pursue these paths without esy.

We're also starting to see other cross-platform Reason-native projects pop-up that I'm very excited about, like Brisk (native OSX UI w/ Reason/OCaml) [3] and Fastpack (native JS bundler - a faster webpack) [4].

Some of my favorite features are the following:

- Esy gives the convenience of NPM / Yarn, but for native development. Importantly, it works great cross-platform - OSX/Linux/Windows. IMO The ease of cross-platform development is one of the JS+Node+NPM workflows greatest strengths, and esy provides this for native development.

- Esy gets faster as you use it. It has smart caching for compiled artifacts - taking into account the full set of transitive dependencies.

- The linking / resolution workflow is incredibly useful for native development. For Revery, we'd often need to try fixes across our GLFW/Fontkit stack, and the link feature made this simple.

I'm biased as I've contributed a little bit to the esy, but I've found the approach to development really interesting architecturally - esy is like a 'React' for dependency management - treating the dependency tree as a "pure function" of (dependency tree -> lock -> build environment) with "memoization" to re-use compiled artifacts.

These are tough problems to solve in native... and I'm really impressed with your work Andrey! Thank you!

- [1] https://github.com/revery-ui/revery

- [2] https://github.com/onivim/oni

- [3] https://github.com/briskml/brisk

- [4] https://github.com/fastpack/fastpack