NyaoVim: Web-enhanced Extensible Neovim Front End | Hacker News Reader

NyaoVim: Web-enhanced Extensible Neovim Front End

github.com

131 pointsgnocchi21 comments

This is really awesome. This is a taste of the fruits of Neovim's development. While my experience with performance in Electron-based editors has largely been poor, the fact that _real vim_ can now be plugged into other editor experiments makes me _very_ excited for the future of editors.

Right, my first thought was that Electron is an instant show-stopper, but it's great to see how far Neovim has gone.

I have to agree - I use Neovim daily but find myself switching for a couple of things (Sublime for whole-project searching and MacDown for live markdown previews). NyaoVim has the potential to take over all of those roles (assuming the performance is there).

Doesn’t building a front end with a kit as heavy and unwieldy as Electron kind of defeat the purpose of a small, light console editor like vim/neovim? Don’t get me wrong, this looks nice, but if I were a (neo)vim user I think I’d be far more attracted to a front end as light as (neo)vim itself.

I get where you are coming from, vi and vim being rooted in low bandwidth light interfaces. However, I think a lot of vi/vim users would like a more fully featured IDE that had the power of vi/vim in terms of usability.

Given the number of vim users I know that install a dozen plugins, I'd wager you're right. Surely, I can't be the only person who uses stock vim, though.

I use both. I have my vim IDE-like with a fair number of plugins. It's my kind of "IDE environment", and for this I would love to get those kind of integrations.

But whenever I have to open a large file, or just make a simple edit to a file on a server, I have a very simple vim with no plugins and a very small vimrc that should work everywhere.

What does that have to do with electron though?

To me, the appeal of VIM is not the lightness, it's the editing paradigm it is based on. I won't be switching to this any time soon, but I can think up plenty of nice features that a html-based view would allow over the terminal, and I wouldn't mind paying (a bit of) a price for it.

The screenshots don't show anything that couldn't be accomplished with a regular text console either, which certainly doesn't help show why anyone would want to effectively run a whole browser just to emulate a terminal.

At the very least, the other "web everything" projects I've seen show something that wouldn't be possible with just a text console.

Don't get me wrong: this is cool.

But... I'm not sure this is a good idea for a full time editor.

Having used Vim for years, then briefly Neovim, I recently switched to Spacemacs (Emacs + Evil) and haven't looked back. The advantage of Vim now is in it's lightness, so I still fire it up out of habit to edit config files etc.

Wrapping Neovim in Electron might well yield a really nice Atom competitor in the future, and it has the advantage that it is easily hack-able through something less esoteric than elsip. I just think it's a tough sell to developers when Spacemacs, Sublime and stock Vim exist.

Even though I am not a fan of `electron.js`, but this looks promising GUI for `neovim`, though some editor properties are not taken from original `.nvimrc`, e.g. theme is different. Which is slight bummer, but hopefully easily configurable.

Fantastic! Trying it now. Love that you used Typescript.

I wonder how this compares to vim-mode in Atom (https://github.com/carlosdcastillo/vim-mode) which is based on those two same technologies..

vim-mode in Atom is like having a Chevy (Atom) and sticking a Ferrari (vim) badge on it.

NyaoVim is more like having a Ferrari (neovim) with an automatic transmission (NyaoVim).

Not a perfect analogy but I think it gets the point across.

There seems to be some dissatisfaction with Electron in this thread. I've heard some good things about building desktop apps on top of Electron but have not had the need to try it yet. I'm curious what people's gripes are.

I have heard that Atom is very slow, but I had chalked that up to the core of the editor being written in a high level language and being subject to stop-the-world GC. Your text editor has to move at the speed of your thoughts (or at least your input).

Given that neovim is implemented as native C and offers a wrapper API, do the same problems exist? Am I misjudging where the issues with Electron/Atom lie?

Atom is getting a lot better, though it used to be pretty bad. I made a video a while ago comparing Atom, VSCode (also Electron), and Sublime Text 3 where you can see the difference.

https://youtu.be/fjR5X-4--kg

But like I said, the current (1.5.x) version of Atom is much faster to load, so they're working on fixing it.

It's not just load time, browsers generally suck at rendering because the CSS/DOM is hardly an optimized spec with plenty of legacy/complexity, and most of the implementations have decades old roots and legacy design decisions as well. Even VSCode which is miles ahead of Atom has rendering performance issues on my laptop - I can see it drops frames when scrolling and stuff like that. Servo is showing how much you can do if you start from scratch on that front, but if you just forgo the entire web stack you can do much better still simply by not having to implement DOM/CSS

So something like Qt or native GUI frameworks are always going to outperform DOM based GUI, and CPUs stopped getting faster so most of these issues aren't going to be solved by hardware improvements (GPU rendering requires a big overhaul of browser stack).

Servo has a "webrender" backend that is GPU-accelerated. While it isn't nearly at feature parity with the established rendering engines, it is an order of magnitude faster at rendering the features that it currently has implemented.

It won't replace your current browser for some years, but I see no reason why it couldn't serve as the engine for something like Electron.

Sure but it's still going to be slower than a native GUI library designed for GPU acceleration because you still need to implement CSS layout and DOM which are suboptimal by design. Maybe by the time Servo lands to mainstream it will be fast enough that it won't matter - but right now that's just not true - DOM is still an inferior platform for GUI because the performance sucks and that's not going to change any time soon - Servo isn't even close to complete yet.

Not necessarily. For instance I believe Nyaovim actually renders to <canvas>. So there is very little dom. I'm sure there is some overhead, but I don't see any reason why the performance can't get on par, if not close to native application performance.

Reply on news.ycombinator.com