
Oni: An IDE powered by Neovim - bsg75
https://github.com/extr0py/oni
======
e_proxus
I think what Electron brings to the table and what most other contemporary
technologies fail at, is cross-platform functionality with minimal effort.

In contrast to most other non-constructive comments about how Electron sucks,
I think the focis should either be how to improve Electron (as mentioned by
others) or on how to improve the cross-platform story for more native
technologies.

What makes Electron so attractive is that it is so very close to write once,
run everywhere. No other technology today comes close, which I think is
evident based on the number of Electron apps out there. There are some native
languages which have great cross-platform stories (e.g. Go), but few of them
seem have a great fronted story. Today the problem is that all major OS
platforms are pushing their own framework and language walled gardens, but I
think most developers would like their apps to be cross platform if they
could. This is an example of where the community has to do it themselves
because the major OS developers seem to have no interest in cross-platform
tools.

What would it take to achieve something like Electron but native? Why hasn't
it been done yet?

~~~
izacus
"minimal effort" \- that's exactly the keyword here. It allows absolute
minimal effort and laziness from developer at the expense of end user.
Electron is a technology that favors developer user experience over end-user
user experience. And you wonder why it is hated?

It's like shitty iOS cordova packaged web apps - they also require "minimum
effort" and "cross-platform functionality". At the tiny expense of horrible
user experience.

> What would it take to achieve something like Electron but native? Why hasn't
> it been done yet?

Are you really that ignorant? Never heard of Qt, SWT, GTK and myriad of other
cross-platform tools and widgets used to develop cross-platform apps since the
80s?

~~~
borisj
It seems hated by some developers such as yourself, yet users of electron apps
seem to quite like them, a lot. Not sure how slack's,spotify's, and
visualcode's success indicate a horrible user experience. What Qt application
has as much reach as slack? Every GTK app I've ever used outside of GNOME
stuck out as out of place with the OS. Maybe some Qt apps flew under my nose
but I'd say the same about them, at least to the extent that they always made
it obvious via certain UI elements that they were Qt apps.

~~~
cmiles74
Slack and Spotify also have web applications that do essentially the same
thing. I would be interested to know how many people download the Electron
version but end up using the website more often, as this forces these apps to
share the same runtime and puts some (meager) limits on CPU usage.

VS Code presents a good experience and it's resource usage is more reasonable,
it's a good example of a successful Electron application. On the other hand,
it has Microsoft behind it and there's probably good reasons why it's so much
more performant than Atom, for instance. I am not convinced it's reasonable to
expect all Electron applications to hit this relatively high bar in terms of
quality.

In my opinion, Electron applications "stick out" as much as any other non-
native application, this isn't an advantage to Electron. Indeed, I think
Electron has proven that people aren't all that interested in a native
application, as long as it's reasonably attractive and the interaction is fun.
This could open the door for a new class of cross platform UI toolkit, one
that drops the faux-native UI in favor of something simple, attractive and
straightforward.

~~~
tracker1
I think that React-Native or similar combined with a control kit based on, for
example Material Design could work very well. I know there's some effort from
the Xamarin guys at MS towards this end. I also think that React-Native itself
could become a better option for more platform-friendly implementations.

------
v-yadli
Are you expecting another Visual Studio or IntelliJ?

I think Electron is a very cost efficient dev environment. Can't really think
of writing all this up in plain C++, wiring up native calls for various OSes,
leveraging GPU, support rapid plugin dev/prototyping etc., etc. Once upon a
time there was Qt, but now it's also doing qml+js..

Even if a NeoVim version of Eclipse (or whatever you think a 'more native IDE'
is) is rolled up, by a small team comparable to oni's, are you going to _pay_
for it?

Oni: 17 contributors, one main dev. IntelliJ: 249 contributors, Github fails
to load stats in one minute.

So why not stop complaining about the IDE and put efforts into optimizing
electron-like platforms? There's still a fat headroom for improvements!
(WebAssembly etc.)

~~~
krageon
The whole idea of electron is that it is built on top of a deeply flawed
framework. I can't speak for anyone else, but I cannot see the appeal to
writing for something that is broken by design.

~~~
thanksgiving
The problem is that, just like Java, electron wins at the end of the day in
terms of market share. If we're in the business of helping people, we can do
more "good" by making an inferior technology slightly more bearable. Of
course, that is just one perspective (not mine but one that I'm trying to
understand as well).

Edit spelling

~~~
snarfy
It reduces software development costs, allowing more software to be written.
There is plenty of software that needs to be written that doesn't exist today.
Reducing costs helps with that need.

The other side of that is software that already exists, running in the
background unnoticed. Things like your graphics driver. You wouldn't want that
written in Java. If it were written in Java you might get a lot of features
faster, but it sure would perform like crap. For core software like that,
development costs are secondary. Performance matters first.

At the end of the day I think we need projects like neovim and oni. Editors
are old technology and should be core software. Performance in my editor
matters. I have five different IDEs installed and I still use vim.

------
juandazapata
I like this idea. This could help novice developers to get to know a true vim
implementation instead of the half-baked vim modes available for other
editors.

Sadly, this is still an Electron app in the background. For comparison, my
nvim install only needs 9.7MB to open a Ruby file with all my plugins loaded,
while Oni requires 165MB just to open a blank file with no custom plugins.

~~~
petre
> Sadly, this is still an Electron app in the background

Same thoughts here. Nevertheless, it's nice that it uses NeoVim as its editor.

I started to use Atom on a daily basis since 1.7 and 1.19 is pretty usable.
Got tired of waiting for an open source editor comparable in features and
functionaity to Sublime Text, but written in a lower level language such as
C++, Dlang, Rust or Go compiled to native machine code. It also looks the same
on every OS and has nice and original features such as automatic whitespace
trimming that I haven't seen in Sublime, or a CSV editing addon for that
matter.

Too bad each app comes with the burden of it's very own instance of Electron.

~~~
juandazapata
I'm glad Atom works fine for you. I was forced to use it for about 2 weeks
(company machine with no installation privileges) and it broke about 5 times.
For reference, I've only seen vim dying once in 10 years (seg fault).

------
se7entime
'IDE powered by Neovim + React + Electron'

Electron, yes Electron

~~~
sdfin
I was wishing this was faster than atom and vscode. I'd find it attractive if
somebody with a good coding reputation proposed in Kickstarter or a similar
site to build something like vscode or atom, but written in Rust or C++.

~~~
Hyperbolic
It's been done. [https://github.com/google/xi-
editor](https://github.com/google/xi-editor)

~~~
mikerathbun
I don’t see how this would be better than just Neovim with a few plugins. I
switched from Vim to Neovim and love it. Highly configurable and rock solid
for everything I have asked it to do. Although I miss things like a live
Markdown editor with preview like what you see in VS Code, but that is a small
price to pay for ultimate control over your editor.

~~~
nallerooth
I use this plugin for previewing markdown [https://github.com/suan/vim-
instant-markdown](https://github.com/suan/vim-instant-markdown)

------
zzzmarcus
Here's another, very similar project, that is still actively maintained.

[https://github.com/rhysd/NyaoVim](https://github.com/rhysd/NyaoVim)

------
trymas
I like the idea of instead creating horrible fake implementations in other
editors, there could be an IDE built on top of true (neo)vim.

Though electron slightly puts off, but not only that, I expected that by
default it will pick up my ~/.vimrc or ~/.nvimrc files, though it didn't. I
have not read in detail, but I can see that configuration is different.

~~~
Gaelan
There is a config option to pick up your ~/.config/nvim/init.vim.

------
kronos29296
Everywhere I see electron apps are being written. Just yesterday saw a file
manager that looks like mc which can only display 100 files and no noise
support in electron.

Now this. I'm speechless.

~~~
gchp
While I also find the surge of electron-based application somewhat amusing,
you can't deny that it has made it easier for more developers to develop
cross-platform applications without having to develop and manage several
codebases with different languages.

I'm working on a side-project at the moment, a large part of which is a
desktop application. Using electron allows me to get a cross-platform app out
the door pretty quickly. If I had a team of more than one, perhaps I would
consider using something else, but as long as it is just me electron just
makes sense.

~~~
keyle
This is correct 100%. At the end of the day, it's about the productivity *
developer head count.

That said it still makes me sick. But what's the alternative? Lazarus? Gtk+?
Yuck.

AIR was looking good, but now everyone is treating it like the plague.

------
linopolus
> Performance - no compromises, VIM is fast, and ONI should be fast too. – the
> Readme

Yeah, that's why you use JS and Electron, right?

~~~
SquareWheel
What do you mean? Javascript is incredibly fast.

~~~
ftxrcc
"incredibly fast"

What

~~~
SquareWheel
Have you not looked at benchmarks? It's one of, if not the fastest interpreted
language. V8 is baked into Electron (and Node), which means Electron can also
take advantage of this speed.

High memory usage I'll give you, but calling it a slow language is very
misguided.

~~~
linopolus
My bad.. ..and that's why you use no compiled language, right?

~~~
SquareWheel
I do use compiled languages, but there's many different tools for the job.
Interpreted languages offer a number of features over compiled, and that makes
it an attractive option in many situations.

In the case of JS, the biggest draw is probably platform portability and the
amount of existing code to utilize. That and speed, as already mentioned.

------
cultofmetatron
Its a great start. I'd love to have an alternative to VScode's shoddy vim
mode. (tends to be buggy for me).

Already the vim mode in this is pretty nice since its powered by an actual
vim.

~~~
allengeorge
I believe this was one of the stated goals of Neovim correct - that it would
be easy to embed in other applications?

~~~
tomjakubowski
A bored, enterprising Emacs hacker could totally embed NeoVim in Emacs for the
evilest-mode.

I wanted to do this a while back, but got stuck because nobody had yet written
a messagepack implementation for Emacs Lisp. And it turned out writing one was
too much like work for me to keep up with it.

~~~
justinmk
This racket msgpack implementation may be helpful:

[https://gitlab.com/HiPhish/MsgPack.rkt](https://gitlab.com/HiPhish/MsgPack.rkt)

Though someone got started on elisp as well.

[https://github.com/kleesc/msgpack.el/blob/master/msgpack.el](https://github.com/kleesc/msgpack.el/blob/master/msgpack.el)

------
simplysh
I love that this is truly batteries-included! I've had such a bad time in the
past setting up reliable omni-completion in vim. I don't know why there's so
much hate for Electron, personally I think this project is great! I was
waiting for something like VSCode with proper vim mode to come along.

~~~
extr0py
Author here - Thanks for trying it out I had the same issue in setting up
omni-completion for JavaScript and TypeScript, and wanted to save others that
pain. It's crazy how much time I spent trying to get YCM to work on Windows
with TypeScript... But I'm really glad it worked out of the box for you!

~~~
simplysh
Yes! It's looking really good so far, I hope you'll continue to update it!

------
jjcm
Great first start. Still a couple weirdisms in it I noticed from first time
use (i.e. ZQ will quit the entire application, not just the file you have
open), but it's nice having full macro support in an electron editor. That's
definitely one of the things I was missing with vscode's vim mode.

------
mmirate
Mods, please append " and Electron" to the post title. Should save lots of
people a click.

------
vogre
Everyone is putting fingers on Electron, but I must say that the worst part of
Oni is Neovim plugins. Even simple things like typescript syntax highlight
don't work as expected.

VSCode is maybe slower and less configurable, but it is years ahead in terms
of language support at least for tsx.

~~~
extr0py
Thanks for trying it out! Yes, language support is still being actively worked
on, and unfortunately the syntax highlighting isn't quite to parity (yet). If
you are able to log an issue with the specific case you are seeing, that would
be very helpful.

It's definitely a goal of the project to be on-par with other IDEs in terms of
language support, but unfortunately we aren't there yet.

------
invalid_
I am still hoping micro gets plug-ins and community support. It has replaced
nano and vim for basics on almost all my devices and work machines.

[https://github.com/zyedidia/micro](https://github.com/zyedidia/micro)

------
adambard
Feels really nice out of the box, well done! Hope to see development continue
on this one.

~~~
extr0py
Cheers, thanks for the support and words of encouragement! :)

------
hannofcart
Well, they could have written a neovim frontend using Ink and JS.

That way you would have a declarative UI framework and be able to code in
React without having to pay the penalties of having to use Electron.

But alas...

------
ezoe
Why does it need to use Electron if it's using the neovim?

~~~
cjbprime
Neovim doesn't come with a graphical interface, which this is. (Though it does
come with an RPC interface for controlling it, which is how this works.)

~~~
kurtisc
Neovim recently added a Qt interface

------
eptcyka
What's the point? Why not just make it a SPA? I really do not need another
electron app running on my system, I can make vim slow enough as it is.

~~~
tracker1
An SPA won't have filesystem access?

