bryphe

There's a cool non-Onivim usage of it called Paravim [2] (and the same author also used it for Vim-Cubed [3])

Revery supports the same FFI as OCaml [1] - C-style linking. I believe Rust would be straightforward to integrate that way - I'm not sure about C#.

I think it's so cool that you can take the ideas of ReactJS - functional programming applied to UI - but then have a language (ReasonML [2]) that is essentially purpose built for it, with OCaml [3] powering it under the hood - a functional programming language that's been significantly invested in, both in academia and industry. And to be able to take React-the-Idea, compile it cross-platform, to native-code... and ship.

This is one of the biggest pieces feedback we've received both the tabs / splits in particular [1], and the more general issue of broader Vim compatibility [2].

We actually use a forked Vim implementation under the hood (libvim [3]) - as the modal-editing engine. So Onivim, in theory, _could_ support everything. The main issue is 'wiring up' features from libvim to our front-end.

We'll be focusing on this in our next milestone (July-Sep) - with the high level goals of supporting more traditional Vim workflows, Vim tab support, along with VimL plugin support and init.vim/vimrc compatibility.

Ultimately it's a prioritization problem - so having feedback like yours is really helpful, so that we can focus on the right priorities for that work.

Oni maintainer here! I agree - I get stressed out sometimes when this gets posted to HN for that reason ;)

I'll piggyback here because this is near the top, but I'll give a couple quick reasons why Electron was chosen for this project:

- Development speed As mentioned in another comment, the React ecosystem has some excellent development tools around hot-reloading / live-reloading. I never found this sort of 'live-reload' workflow in any of the C/C++ toolchains I've used. (Would be interested if that has changed!)

For a very small team, this is an important consideration! It's the difference between Oni existing as an Electron app vs. not existing at all.

- Developers Oni is an open source project, and I open-sourced it because I wanted help building it (and I've been fortunate to work with some amazing contributors [1]). When you look at the last StackOverflow Developer Survey [2], web tech is overwhelmingly at the top - if I want help, I should pick the tech stack that has the broadest appeal.

Every editor is an exercise in trade-offs, and of course Electron brings trade-offs of its own. Oni is an experiment in a different (not necessarily better, because that's subjective and relative to each person's workflow) set of trade-offs than other editors - an attempt to bring together the "modern" functionality of editors like Code/Atom with Vim. It resonates with some people, but it's not going to be for everyone, and that's OK.

Even if you don't use Oni or agree with the tech stack, these sorts of experiments are important, because if new ideas or workflows work well... they can find their way into your editor of choice, too.

One other note - I focused a lot on Electron, but the project wouldn't be here without neovim, either! They've done excellent work, and there is quite a variety of front-ends - so even if Oni isn't your thing, I'd encourage to check out that project as well as some of the front-ends for it [3].