
NyaoVim: Web-enhanced Extensible Neovim Front End - gnocchi
https://github.com/rhysd/NyaoVim
======
jzelinskie
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.

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

------
kitsunesoba
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.

~~~
DigitalJack
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.

~~~
groovy2shoes
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.

~~~
roblabla
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.

------
bananaoomarang
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.

------
trymas
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.

+1

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

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

~~~
phairoh
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.

------
cjhveal
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?

~~~
kungtotte
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](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.

~~~
moonchrome
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).

~~~
nwah1
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.

~~~
moonchrome
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.

~~~
tshannon
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.

