oni

is 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

+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

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

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]. [1] - https://github.com/onivim/oni/graphs/contributors [2] - https://insights.stackoverflow.com/survey/2018/#technology [3] - https://github.com/neovim/neovim/wiki/Related-projects