I've found Helix Editor to be a good successor [0], although it's still in development. Vim-like modal editing with fast performance due to being written in Rust rather than Electron.

[0] https://helix-editor.com/

I was supporting Oni2 for the same reasons, a work-out-of-the-box fast modal editor but a Gui would have probably meant leaving behind a terminal based workflow.

I have also been seduced into Kakoune's way of doing things although not enough to make the jump from vim, which I hate but can't live without.

Helix really hits that sweet spot of a fast work-out-of-the-box kakoune-style terminal editor. Time to make the jump.

Unfortunately the reason I switched back to Neovim is that Helix doesn't have plugin support yet, so one can't really add new features, even if most of the popular ones are built in, like tree-sitter.

Some anecdata. I've started using Helix too, and found it surprisingly good (relearning some not-so-vim stuff wasn't a problem). But I returned back to NeoVim purely because of... Copilot. Hard to code now without Copilot, and it's only available in VSCode and NeoVim ¯\_(ツ)_/¯

Yes, that is also why I came back to Neovim. Another con is that Helix doesn't have plugin support yet, so one can't really add new features, even if most of the popular ones are built in, like tree-sitter.

How can it be a successor to Oni if it's terminal-only application?

Due to speed and vim-like editing, with certain things like tree-sitter support built in, similar to how Oni has things built in. With (Neo)Vim you'd have to configure that yourself. That it's terminal versus GUI doesn't make much difference to me, since as long as it shows text/code on the screen, I don't really care how it displays it.

OniVim's main selling points was it beeing close to VSCode, so saying Helix Editor is its successor but not having the main features does not make a lot of sense to me. Based on your points it sounds like Helix Editor is pretty much the same as SpaceVim.

I used OniVim due primarily to speed and not having to set up a vimrc. That it was a GUI app versus terminal based is immaterial to me. Now I have my own vimrc so it doesn't matter much anymore, but last year OniVim was nice enough to use.

As stated already - the main selling point of Oni is\was VSCode-like UI, ease of extension installation etc.

Speed or vim-like editing was not a selling point at all.

>I doesn't make much difference to me

Okay, but this is completely beyond the point.

> Speed or vim-like editing was not a selling point at all.

Speak for yourself, those are why I supported OniVim. The GUI was not what was important to me, it was the ability to install extensions easily, have vim keybindings, and most importantly, be able to handle the very large files I often work with (due to being written in OCaml), where VSCode hangs.

>Speak for yourself, those are why I supported OniVim.

Why are you so obsessed with this subjectiveness? I'm just saying that speed and vim-like editing where not a selling point. Because you can already have those in VSCode with neovim backing it up. Not to mention you could've already have speed and vim-like editing via projects like VimR (tens of them out there).

>The GUI was not what was important to me

>I thought OniVim would bring that^1 but it seems it is not anymore.

You are contradicting yourself here.

[^1]: "(neo)vim plugin installation still isn't as easy to work with as a one click package / language server install like in VSCode."

On the contrary, I think it is you who is obsessed with what I should or shouldn't think of as a selling point. I used to use VSCode, it was slow, I found OniVim and it was fast, why is that so hard for you to accept as the reason I liked and bought the application? As I said, speak for yourself, if speed wasn't a consideration then good for you, for others it is.

Regarding the plugin support, there is no contradiction. Rather than the words "one click" however, which brings to mind a GUI, I should have said Neovim has a more annoying plugin story (through packer which has a lot of configuration) than VSCode or OniVim, yet it is not the GUI that makes it so. If I could write in init.nvim "Plug TypeScript" just as in VSCode I could click "install" on the TypeScript extension, those are both equivalent to me, even as the latter is GUI based while for former is terminal based.

To be honest it seems vim/neovim ticks all those points already.

Yes, however (neo)vim plugin installation still isn't as easy to work with as a one click package / language server install like in VSCode. I thought OniVim would bring that but it seems it is not anymore.

I was really hope for that to turn out well, but alas, but to Emacs or Neovim I go. I even paid for an Onivim2 license.

If I had to bet, I would guess that the ReasonML > Rescript drama/change killed a lot of the momentum in the community.

I'm only vaguely aware of the change. Can you elaborate?

You can read about the ReScript change here: https://rescript-lang.org/blog/bucklescript-is-rebranding

I wouldn't go so far as GP as to call it "drama", but the split left Reason without a reason (pun intended) to exist or any activity for that matter. Most of the people who liked Reason for frontend usecases moved to ReScript since that at least had some momentum behind it. Since the split, Reason itself has been largely on life support, with no significant changes and almost no forum activity in the past year. So newcomers to Reason see a dead community for a language which is a syntax extension for another language with a (relatively) alive community. The fact that Reason hasn't seen a surge in enthusiasm corresponding to the enthusiasm in the OCaml community with the advent of 5.0 and multicore is proof enough that Reason is dead, and projects written in Reason should probably consider moving to OCaml entirely considering there are planned changes to the OCaml syntax for effects which I don't think are going to make it to Reason.

Some people in the Reason world blame the ReScript people for this, which I think is entirely misplaced. The only reason (pun not intended this time) Reason has died off is that there is absolutely no clarity on the future of Reason. The creator of Reason, Jordan Walke, has been entirely MIA for about two years now. A version 4.0 was planned in 2020 and as of now hasn't come up. This issue was opened in Nov 2020 asking for future plans and is still unresolved, and the latest comment from a new developer just makes my point: https://github.com/reasonml/reason/issues/2634.

Agree with you, Reason is effectively dead, the "drama" part is that the decision came from nowhere, leaving the native devs with a sour taste and the frontend devs with a "Hey, we just changed the syntax without warning and will not support the old one anymore, good luck", which made me move all my projects out of reason ASAP, if the developers can pull out giant changes like that without warning, sorry, I will not use it, too unpredictable.

Also, rebranding instead of starting a new project sounds just like "it's my baby, I'm gonna kill the old project so no one that disagrees with my decisions can continue it".

> Some people in the Reason world blame the ReScript people for this, which I think is entirely misplaced.

I mean, the way that the creator of ReScript behaved on discord to any criticism to his decisions at the time didn't helped...

> "Hey, we just changed the syntax without warning and will not support the old one anymore, good luck"

I think this is slightly uncharitable. The people working on BuckleScript had been unhappy about syntax for a while, and wanted to make it simpler for people coming from JS. They also kept supporting Reason syntax - it's quite literally in the announcement and forum threads from the time that old code will continue to work.

I can't speak to why the rebrand went down the way it did, as none of us can know for sure, but I think it might have more to do with internal communication between team members than any one person taking their toys and going home, so to speak.

> I mean, the way that the creator of ReScript behaved on discord to any criticism to his decisions at the time didn't helped

I didn't hang around on the Reason discord (for good reason, I now suppose :P) but I don't think that had anything to do with Reason dying out. No matter how the ReScript people behaved, Reason native could've gone its own way, but it didn't, and the responsibility for that is on Reason. As much responsibility as there is, ofc. I don't mean to imply that the team behind Reason should've continued developing if they didn't want to, I just don't think the ReScript people should be held to account for how Reason evolved.

(FWIW, I was interested in Reason only for native, and have zero interest in ReScript, so I say this as someone who is "on your side".)

> The people working on BuckleScript had been unhappy about syntax for a while, and wanted to make it simpler for people coming from JS.

Yeah, but as far as I remember the new syntax and all changes were discussed and developed behind closed doors and dropped like a bomb, I mean, it is their project and they could do whatever they want, but two points left a pretty sour taste in my mouth:

1. You know that there are a lot of native projects and your changes will cause ripples through the entire ecosystem, warning people would be nice, they have no obligation to do so, but they can't really complain that people were pissed about it.

2. The rename and using all the old bucklescript resources instead of passing these resources for the community and saying "ok, now we're working on ReScript, it is a new language that follows our long term vision for the future of webdev, follow us". They own the project, but they don't "own" the community.

> I didn't hang around on the Reason discord (for good reason, I now suppose :P)

Yeah, it wasn't a nice place.

As for reason dying out, most of the devs that embraced native ReasonML were also OCaml devs and tooling was being developed to facilitate the transition from web to native code with the more approachable syntax of reason (esy.sh and revery were two of these initiatives).

ReScript dropping support for OCaml was like "ok, no point in trying to bring web people to native now, let's stick with OCaml syntax, they aren't the same language anymore".

And as "my side", I did use Reason syntax in native just because I was already using the syntax in web projects, otherwise I would just write OCaml, but after seeing how the changes were announced I gave up on Reason for web and didn't even bother with ReScript, don't get me wrong, it is a really nice language for webdev, but I have no interest in waking up in a Monday just to discover that the language I'm using is being completely changed without any warning in the next week.

This. The reason for Reason to exist was to be a bridge, bring native OCaml devs to web deployment and bring front end devs to native apps. It was a brilliant strategy I think. While the failure of the project certainly stems for the absence of development for more that two years, the ReScript project was the last nail the coffin because it stated that they wanted to blow up the bridge that was Reason's reason to exist. Why they thought the world needed yet another compile-to-javascript dialect when there's already typescript, dart, elm, and probably many others is beyond me.

To be fair, you can still use Reason code in a ReScript project. However, the community has diverged.

The creator of bucklescript (ReasonML/OCaml to JS compiler) decided to drop ocaml support and gather the already built community around his new project (Rescript) and it wasn't well received by the part of the community that were interested in ReasonML (and OCaml) for native or hybrid applications, which is kind of obvious since:

1. Rescript is not ReasonML/OCaml, it is a new language.

2. Rescript doesn't compile to native code.

Forks were being discussed, the creator didn't like the criticisms of his decision (which came as a surprise for most of the community), people didn't liked having the rug pulled out of their feet, aggressive comments were made, people were angry and the community got separated between web and native, both weaker than the united one.

TL;DR; The creator decided that his project was for web only, alienated the native developers out of the blue and shattered the community.

The reason why you shouldn't go for obscure frameworks for new projects and stick to popular libraries like vue react

Funny thing, ReasonML (the alternative syntax for OCaml) was created by Jordan Walke, who also created React.

The cool thing about Bucklescript is that it generated pretty readable javascript, so dropping the compiler and working with the JS files was pretty easy, which is what I did with a project that I was working when the drama started, just used the generated js files and slowly replaced them with typescript when needed.