MacVim or gvim is still a regular native app without a js vm and a web enviroment. It's less minimal then terminal vim, but way more minimal than electron.

I don't mind electron myself, but that ps sounds fairly disingenuous to me.

The kinds of things in your comment are the kind of things that make me consider actually installing Oni rather than just going "oh neat, people are making Neovim frontends" like I did when I first saw this post.

The only thing that makes me hesitate is because I run FreeBSD on some of my computers and FreeBSD support wasn't quite there yet for Electron apps last I checked. It may have changed in the meantime.

If I were to begin using an Electron app, I need to be sure that I will be able to use it on my FreeBSD computers also. This is especially important for editors and IDEs given that writing software is rather central among the things that I do. Currently I use Neovim for a lot of things and I use PyCharm for bigger Python projects.

I am wondering though, would it be feasible for one person (me) to rewrite Oni so that one can use it from within their web browser instead of with Electron?

I liked the irony in this post, considering that the main draw of Electron apps is that they are supposed to be cross-platform. (To be fair though, FreeBSD is pretty niche.)

I don't consider any framework cross-platform unless it also targets TempleOS.

Would be interesting to see if we could compile Neovim via WebAssembly... If that's the case, it would certainly be feasible to run Oni in the browser with a few (minor) tweaks. The UI layer is react-based and would be trivial to run in a browser.

Interesting project that did something similiar for Vim: https://github.com/coolwanglu/vim.js/

Electron does provide quite a lot of apis that do not exist (and hopefully never will) in browsers. Namely, complete access to the filesystem. It also does provide a way of creating native plugins.

I have not looked into the way neovim communication works but from their site it seems to be using named pipes which are again, not available from a browser.

Access to the file system can be done via HTML 5 File API.

The File API is very limited in comparison what can be done with the Electron fs API which has direct access to the file system.

Which is a lame excuse for using Electron disguised as native app, in a connected world, even native apps should be sandboxed by default.

I seriously doubt it would be impossible to use Electron as it really is, a Web App.

As much as I prefer real native applications and like hating on electron, I have to give it some credit. It is not just chromium, it is chromium+nodejs and all the stuff that comes with it.

The answer to "would it be feasible/easy to port an Electron app to a pure browser app" is no. Unless all of the communication between the frontend part and the native tooling is done via sockets.

I agree that native apps should be sandboxed, however sandboxing something like an IDE will be quite difficult. Even Apple does not sandbox Xcode.

> Unless all of the communication between the frontend part and the native tooling is done via sockets.

Admittedly I have not developed any Electron apps, but I have developed serious web apps and worked a little bit with NodeJS also.

Why don’t people do exactly that when they write their code — make all communication happen over regular HTTP and websockets?

Some data is not suited to go through asynchronous streams with a lot of parsing. At some point I needed to pass real-time eeg data to an application and we were exploring Cordova as an option. The jitter and absurd latency (over 15ms) was a non-starter. Things might have gone better but not everything can be solved by immutable data structures.

For comparison, the same data transfer using Electron native plugin took well under 1ms.

Can you tell us the benefits of running freebsd on a development machine?

I just feel at home with FreeBSD. I mean it’s not perfect. That’s why I run FreeBSD on some and not all of my computers and instead run Linux on the rest (and also macOS on one of them).

I like the idea of the same group of people maintaining the kernel and the userland utilities.

Also I am strongly in favor of the family of BSD/MIT/ISC licenses over GPL.

I love ZFS. I think dtrace is neat. I think jails are nice. I like pf. Nowadays there are equivalents for pretty much all of that on Linux. In fact you don’t even have to go with btrfs to get something like ZFS on Linux — the ZFS on Linux project makes ZFS available on Linux too. But on FreeBSD all of these things are there in the base install without having to do anything special and they will continue to be there for a very long time.

All in all, I just like FreeBSD a lot, and I feel at home with it in a way that few other systems make me feel.

Thanks for your support, Justin! Oni wouldn't be here without the awesome work you've done:)

Neovim has been a joy to build on - fast, performant, and stable. Great example of a high-quality OSS project!

Native Mac apps can be crazy fast. Haven’t seen a reasonably fast Electron app yet. Plus you lose wonderful native Cocoa text features, such spelling, dictionary, undo, etc.

Sorry I never used a Mac, but how can undo be a "wonderful" features ???

Undo on native Cocoa apps have a few delightful “smarts” that you begin to take for granted and can be infuriating when absent.

For instance, native undo is time and word sensitive. I don't know its exact heuristics, but it always seems to do what you meant.

Gmail's Chrome and Electron, on the other hand, will often undo letter by letter or leave you in mid typed words, which is nuts.

If you want another example, I often write in multiple languages, something that's beautifully handled for you on native apps. Since Skype changed to Electron, it puts a red underline on every single non english word I type and there is nothing that can be done about it, besides changing the default system language and restarting the app.

There's also CoreText's sharp line width in retina displays no matter which background/foreground color combination you choose, built in dictionary a tap away, etc.

It's just a dreadful experience otherwise, once you get used.

The features mentioned are built into the standard macOS toolkit, which makes them handily available and consistent between applications. I don't think they were listing them for being unique as much as pointing out the feature consistency.

you can use nvim-qt or neovim-gtk and keep having a minimalism experience.