Oni – Modern Modal Editing(onivim.io)
onivim.io
Oni – Modern Modal Editing
https://www.onivim.io/
95 comments
> I don't understand this obsession with mouse-less text editing
For your information: the issue with mouse-laden text editing is that you need two hands on the keyboard to type, so you are repeatedly moving a hand between the keyboard and the mouse. This takes time: in my experience enough time that it's often faster for me to use keyboard navigation _anyways_. Plus the constant wrist motion can be bad for RSI.
That said, if you can edit more efficiently with the mouse, and your wrists don't hurt, then go for it.
For your information: the issue with mouse-laden text editing is that you need two hands on the keyboard to type, so you are repeatedly moving a hand between the keyboard and the mouse. This takes time: in my experience enough time that it's often faster for me to use keyboard navigation _anyways_. Plus the constant wrist motion can be bad for RSI.
That said, if you can edit more efficiently with the mouse, and your wrists don't hurt, then go for it.
Yeah, I've been spending a lot of time on my laptop, actually. I'm quite used to the trackpad being really close to the keyboard. It hasn't been a lot of strain.
I'm surprised that TrackPoints aren't more popular for this reason.
I don’t hate the mouse but moving my hand from the keyboard to the mouse repetitively hurts my hand and shoulder.
It gets fatiguating after a while. If you are doing lots of selection, moving around, insertions, etc it accumulates.
I only use vim for any text editing. I also use a vim plugin to navigate chrome. And several other keyboard shortcuts to navigate macos. The accumulation really helped.
It gets fatiguating after a while. If you are doing lots of selection, moving around, insertions, etc it accumulates.
I only use vim for any text editing. I also use a vim plugin to navigate chrome. And several other keyboard shortcuts to navigate macos. The accumulation really helped.
Acme's big thing isn't the mouse. It's the plumber and regex-based logic, which has the effect of making the mouse more useful. But the same would be true of the keyboard, it just hasn't made it into a popular implementation yet, probably for lack of plumber on popular unices. There was a project on GH that tried to do acme/Sam with the addition of keyboard modal; it would make a very powerful editor. Here it is:
https://github.com/driusan/de
I currently use kakoune which is probably the closest thing to that idea in a production ready editor, only the 'plumber' is done with shell commands, which can send variables back to running instances, so it's more DIY than plan9 plumbing.
https://github.com/driusan/de
I currently use kakoune which is probably the closest thing to that idea in a production ready editor, only the 'plumber' is done with shell commands, which can send variables back to running instances, so it's more DIY than plan9 plumbing.
Well at least for me the best of Vim includes running my editor in a terminal, so I wouldn't quite say that Oni has the best of Vim.
You know, I've always been fascinated by this statement. Why is it more comfortable for you to be in a terminal?
(For the record, I currently use Macvim but am deeply interested in Oni and other projects. I've been a vim user for many years now and consider myself reasonably proficient, although, you know, it's vim after all, there's always more to learn).
(For the record, I currently use Macvim but am deeply interested in Oni and other projects. I've been a vim user for many years now and consider myself reasonably proficient, although, you know, it's vim after all, there's always more to learn).
In my terminal everything is a string. All of my tools are run from the terminal ( cloud provider, provisioning software, etc. )
I can chain cli calls together to create powerful workflows.
I have highly scriptable workspace management with tmux + vim.
I don't have to wait for web pages to load to run commands, I can just do the thing in the same place I do everything else.
Many people don't gain that much from the terminal but if you are a power user it makes your life great.
I don't like GUIs, they take too much space, are always trying to sell me something, present information in an inferior way ( I like my dark, cool colored termina l color palette ), and I can't script repetitive tasks.
most cli tools have the same conventions so learning new tools has way less overhead.
Just a few reasons.
I can chain cli calls together to create powerful workflows.
I have highly scriptable workspace management with tmux + vim.
I don't have to wait for web pages to load to run commands, I can just do the thing in the same place I do everything else.
Many people don't gain that much from the terminal but if you are a power user it makes your life great.
I don't like GUIs, they take too much space, are always trying to sell me something, present information in an inferior way ( I like my dark, cool colored termina l color palette ), and I can't script repetitive tasks.
most cli tools have the same conventions so learning new tools has way less overhead.
Just a few reasons.
Because I already live in my terminal for everything else, and I'm constantly opening and closing my editor, and that's slower when it spawns a new window.
I recently installed a plugin that lets me open MacVim with a shortcut (https://github.com/cknadler/vim-anywhere). Everytime I use it I remember why I avoid the GUI.
I recently installed a plugin that lets me open MacVim with a shortcut (https://github.com/cknadler/vim-anywhere). Everytime I use it I remember why I avoid the GUI.
I don't really understand the "line in my terminal for everything else" reasoning, as I don't mind alt-tabbing.
But I really don't understand the "constantly opening and closing my editor" thing. I'm usually working on one or two projects at a time at most, and just keep a window open to that project. This is pretty much how most people work. Why doesn't that work well?
I'm genuinely asking btw. I'm not sure why loving vim is so correlated with working with your editor in such an unstandard way. (I mean, I'd guess it's the opposite - people like me come to vim for reasons having nothing to do with that, and try to use it like our old IDEs, whereas people who started off wanting to do everything in the terminal look for a solution and find that vim fits them. But that's just a guess).
But I really don't understand the "constantly opening and closing my editor" thing. I'm usually working on one or two projects at a time at most, and just keep a window open to that project. This is pretty much how most people work. Why doesn't that work well?
I'm genuinely asking btw. I'm not sure why loving vim is so correlated with working with your editor in such an unstandard way. (I mean, I'd guess it's the opposite - people like me come to vim for reasons having nothing to do with that, and try to use it like our old IDEs, whereas people who started off wanting to do everything in the terminal look for a solution and find that vim fits them. But that's just a guess).
Treating your shell as the environment and an editor as just one tool among many is a perfectly internally-consistent approach. Standard, even, considering how many of us do it. I don't claim it's the only workable way. Do us the same courtesy.
"I don't claim it's the only workable way. Do us the same courtesy."
I'm sorry, I didn't mean to offend. As I said - I'm genuinely curious as to what you feel makes this method better. I wouldn't be wasting my time asking if I didn't think there was a chance I might learn something that would make me change the way I work - that's how I picked up vim in the first place, not to mention every other improvement I've ever made in my life.
I'm sorry, I didn't mean to offend. As I said - I'm genuinely curious as to what you feel makes this method better. I wouldn't be wasting my time asking if I didn't think there was a chance I might learn something that would make me change the way I work - that's how I picked up vim in the first place, not to mention every other improvement I've ever made in my life.
It's all good, just be careful with words like "standard" and phrases like "like most people". They can subconsciously hinder learning.
This is a subject that has been hashed to death online, especially in Vim vs Emacs discussions. Emacs behaves more like an IDE, as an environment rather than a tool. Vim is further along the tool side of the spectrum (though I sense Plan 9's Acme is even further along; Vim is actually pretty moderate, believe it or not). Gvim tries to bisect the difference, but I find it to be the worst of both worlds: not as nice an experience as say Idea or PyCharm, but also encouraging "bad habits" from the terminal point of view, such as using the mouse. Or navigating where you are in the system from within the editor rather than the shell.
I actually do use multiple windows and Alt-tab between them. It's just that most of them are terminal/shell/tmux windows. I do use other apps too (like a web browser). But for text processing and navigation the shell is what I like best.
Anecdotally Vim users seem more sensitive to even small latencies, and GUIs invariably seem to introduce lag. Though I'm finding that I'm more tolerant of lag in my non-shell windows. Using VimAnywhere has made that clear because it causes the "universes to collide".
This whole question is actually not that important, in my opinion. You were right above that it's mostly about what way you start out in. If you're reasonably effective with one set of tools, to try to switch is to bait big to catch small. There's far better uses of your time out there. Perhaps the only thing to learn is that there are many ways to skin the cat. There, now move on.
This is a subject that has been hashed to death online, especially in Vim vs Emacs discussions. Emacs behaves more like an IDE, as an environment rather than a tool. Vim is further along the tool side of the spectrum (though I sense Plan 9's Acme is even further along; Vim is actually pretty moderate, believe it or not). Gvim tries to bisect the difference, but I find it to be the worst of both worlds: not as nice an experience as say Idea or PyCharm, but also encouraging "bad habits" from the terminal point of view, such as using the mouse. Or navigating where you are in the system from within the editor rather than the shell.
I actually do use multiple windows and Alt-tab between them. It's just that most of them are terminal/shell/tmux windows. I do use other apps too (like a web browser). But for text processing and navigation the shell is what I like best.
Anecdotally Vim users seem more sensitive to even small latencies, and GUIs invariably seem to introduce lag. Though I'm finding that I'm more tolerant of lag in my non-shell windows. Using VimAnywhere has made that clear because it causes the "universes to collide".
This whole question is actually not that important, in my opinion. You were right above that it's mostly about what way you start out in. If you're reasonably effective with one set of tools, to try to switch is to bait big to catch small. There's far better uses of your time out there. Perhaps the only thing to learn is that there are many ways to skin the cat. There, now move on.
> I don't really understand the "line in my terminal for everything else" reasoning, as I don't mind alt-tabbing.
What exactly don't you understand about it? For me it's the single most frequently used environment, I can do more things and do them faster than in any other way. What is there about it not to understand?
Then, I don't mind alt-tabbing either. I do mind, however, the amount of it. I have multiple terminals open and I operate at the limit of my abilities to manage them. With a separate GUI window, I would either have one more window to switch through (and thus I would be over my limit) or have one terminal less to execute commands.
> But I really don't understand the "constantly opening and closing my editor" thing.
A workflow thing. I don't understand people running GUI for version control, or GUI for simply opening a file in a directory tree, yet people do that all the time.
What exactly don't you understand about it? For me it's the single most frequently used environment, I can do more things and do them faster than in any other way. What is there about it not to understand?
Then, I don't mind alt-tabbing either. I do mind, however, the amount of it. I have multiple terminals open and I operate at the limit of my abilities to manage them. With a separate GUI window, I would either have one more window to switch through (and thus I would be over my limit) or have one terminal less to execute commands.
> But I really don't understand the "constantly opening and closing my editor" thing.
A workflow thing. I don't understand people running GUI for version control, or GUI for simply opening a file in a directory tree, yet people do that all the time.
The thing about vim is that it readily supports both modes of operation. I'll open one long running vim process per rails project I'm working on, and I use the --remote option on the command line if I want to open related files in that running vim.
But it's also nice to pop open a new vim in any old directory to deal with one or two edits that don't belong to a real project. I do this all the time when dealing with docker or Dev ops type tasks that don't require managing a lot of code.
But it's also nice to pop open a new vim in any old directory to deal with one or two edits that don't belong to a real project. I do this all the time when dealing with docker or Dev ops type tasks that don't require managing a lot of code.
For me, as a data point, there are a couple of reasons.
1) Because when I started programming, that's what I used. I'm comfortable in it because I'm comfortable in it :-) I'm pretty sure that's most of the issue to be honest. When I've asked people what they like most about their graphical IDEs, I've come away with the impression that the same thing governs the majority of their preference: it's what they are used to.
2) My vision is poor. I use a 22 point font. The layout of most GUI programs tends to leave no room for editing if I use the same kind font size (I also have poor peripheral vision, so I use a 13" display which fits comfortably in the section of space that I can see). Things like menu bars, file trees, object trees, test panels, etc, etc are more than useless to me. If I close all of them down, I'm left with exactly what I have in my terminal window.
3) I don't like to use a mouse. I use a tiling window manager. Often I work in tmux (for which I've set up key bindings exactly the same as my tiling window manager) and I might not even have X running (I probably have the most tricked out linux console of anybody I've ever heard of). I used to have a trackball, but I've given it up and now work exclusively with a laptop with a track pad because I've gotten myself to the point where I almost never have to use it.
4) Performance. I have 8 gigs of memory in this laptop. I have swap turned off. I almost never use more than 2 gigs at a time (sometimes I have a VM which has 2 gigs allocated to it, so then my memory usage creeps up to 4 gigs). Lots of memory for file buffers :-) People are always amazed at how responsive my machine is, despite being a 3 year old i5 mobile processor with 8 gigs of memory. IDE's are bloatware for me. I won't use the extra features anyway.
Most of this is personal, but that's what you get for preferences. A few people I've worked with have seen my setup and have gone a similar way. I know a couple of people who also live in Emacs -- they never leave Emacs if they can help it because everything is completely integrated in a way that you just can't do in other environments (that I've seen, anyway).
In the late 90's I worked on Windows stuff and my employer forced me to use Visual Studio (yeah, employers actually pulled crap like that in the 90's). I eventually modified it to the point where I liked it quite a lot. I'm sure I could do the same with most IDEs out there now, but there's no point. The terminal gives me everything I want at minimal resource overhead.
1) Because when I started programming, that's what I used. I'm comfortable in it because I'm comfortable in it :-) I'm pretty sure that's most of the issue to be honest. When I've asked people what they like most about their graphical IDEs, I've come away with the impression that the same thing governs the majority of their preference: it's what they are used to.
2) My vision is poor. I use a 22 point font. The layout of most GUI programs tends to leave no room for editing if I use the same kind font size (I also have poor peripheral vision, so I use a 13" display which fits comfortably in the section of space that I can see). Things like menu bars, file trees, object trees, test panels, etc, etc are more than useless to me. If I close all of them down, I'm left with exactly what I have in my terminal window.
3) I don't like to use a mouse. I use a tiling window manager. Often I work in tmux (for which I've set up key bindings exactly the same as my tiling window manager) and I might not even have X running (I probably have the most tricked out linux console of anybody I've ever heard of). I used to have a trackball, but I've given it up and now work exclusively with a laptop with a track pad because I've gotten myself to the point where I almost never have to use it.
4) Performance. I have 8 gigs of memory in this laptop. I have swap turned off. I almost never use more than 2 gigs at a time (sometimes I have a VM which has 2 gigs allocated to it, so then my memory usage creeps up to 4 gigs). Lots of memory for file buffers :-) People are always amazed at how responsive my machine is, despite being a 3 year old i5 mobile processor with 8 gigs of memory. IDE's are bloatware for me. I won't use the extra features anyway.
Most of this is personal, but that's what you get for preferences. A few people I've worked with have seen my setup and have gone a similar way. I know a couple of people who also live in Emacs -- they never leave Emacs if they can help it because everything is completely integrated in a way that you just can't do in other environments (that I've seen, anyway).
In the late 90's I worked on Windows stuff and my employer forced me to use Visual Studio (yeah, employers actually pulled crap like that in the 90's). I eventually modified it to the point where I liked it quite a lot. I'm sure I could do the same with most IDEs out there now, but there's no point. The terminal gives me everything I want at minimal resource overhead.
The number one reason for me to use vim is also to be able to use it in a terminal. The number one reason for a terminal is to have a consistent current directory. When I double click gvim, I immediately lost. I guess you could launch editor from file, and it's OK if the file is in isolation. For me, it is never the case.
And being available on most distros, even if it's a basic version or just old school vi.
Why use vi when you have ed.
Why use ed when you can shoot yourself in the foot?
Happy medium:)
Looks cool. They seem to say it's based on neovim, so it's actually an interface to the real thing, then. A shame their website is so cryptic and the link to their source control host is not easy to find.
There's a big github icon on the front page up to the right leading directly to their git repo...
Oni is really cool, but still early days. Since it's just a frontend for neovim it actually seems to use less ram than Atom and VSCode. But VSCode has a big head start and a team behind it optimizing stuff the best they can. I'd love to see where Oni find itself in a year or two as I do believe that it could outperform VSCode in the future. Both Oni and NeoVim got a long road ahead of work.
I hate these posts, because Hacker News is incapable of talking about an Electron based project productively.
Yeah, it could be done more efficiently without a full blown browser engine, everyone knows that. But honestly, who doesn't already get that? It hasn't stopped me from using VS Code regularly, which is already more performant than IntelliJ imo, an app that doesn't use Electron.
Almost everything that can be said on this front has been said. Does it really need to be the top 3 comments every time?
Yeah, it could be done more efficiently without a full blown browser engine, everyone knows that. But honestly, who doesn't already get that? It hasn't stopped me from using VS Code regularly, which is already more performant than IntelliJ imo, an app that doesn't use Electron.
Almost everything that can be said on this front has been said. Does it really need to be the top 3 comments every time?
I understand your frustration, but in a world with a dozen different languages to choose from for cross platform native desktop apps, there's very rarely a case to be made for electron even existing.
I'm not trying to prove your point by making the insufferable comment that you hate and already expect, so please understand I am genuinely interested:
Why would, or why should, a person interested in creating a cross platform desktop app, choose electron?
If it's just to use their favorite web components to design with, is that really a good enough reason? When GTK and Qt both provide js api capabilities, what else is there to gain?
Please understand, I'm not a web developer, I'm not familiar with most of it, but just the thought of 100+MB overhead for an app is completely unacceptable to me. But again, the benefit of using web tech is lost on me.
I'm not trying to prove your point by making the insufferable comment that you hate and already expect, so please understand I am genuinely interested:
Why would, or why should, a person interested in creating a cross platform desktop app, choose electron?
If it's just to use their favorite web components to design with, is that really a good enough reason? When GTK and Qt both provide js api capabilities, what else is there to gain?
Please understand, I'm not a web developer, I'm not familiar with most of it, but just the thought of 100+MB overhead for an app is completely unacceptable to me. But again, the benefit of using web tech is lost on me.
There aren't a dozen different languages. I'm not even sure that there's a single one with an attractive story on Windows + macOS + Linux. Gtk doesn't work well on anything other than Linux/Unix (not macOS).
So it's mostly Qt vs Electron. Having to compile different binaries for every Linux distro and version makes Qt a non-starter for most. And if you're going to compile it statically to try to avoid that dynamic linking nightmare, you just added more bloat to your download than Electron.
Qt is hardly a popular toolkit for Windows and macOS apps.
And if I use Electron and React, I get to add native-ish mobile apps for little extra work by using React Native there.
So it's mostly Qt vs Electron. Having to compile different binaries for every Linux distro and version makes Qt a non-starter for most. And if you're going to compile it statically to try to avoid that dynamic linking nightmare, you just added more bloat to your download than Electron.
Qt is hardly a popular toolkit for Windows and macOS apps.
And if I use Electron and React, I get to add native-ish mobile apps for little extra work by using React Native there.
I have done years of web dev, including modern React UI, as well as years in the past with Java Swing and Qt/C++, so I have a little perspective here. Electron offends my sensibilities for precisely the reasons you outlined. However, these are my thoughts:
1. It enables a large swatch of people that have never done desktop development (which has a learning curve that is hard to climb if you aren't paid to do it) to build cool stuff and ship it. Without Electron, we'd be left with nothing. If nothing is truly better than something with Electron, then this won't be a compelling point. However I'd rather have stuff that I ignore than to not have stuff.
2. Performance in electron can be decent. It isn't always because of bloat and poor implementation, but that can be true of native apps as well (especially java-based ones). The download size is laughable, but hard drives are reasonably sized these days so this is less of a pragmatic concern, and more of an ideological purity concern.
3. The modern paradigm that React brings to the table can genuinely be a better dev experience than the traditional frameworks. The benefits of "always re-render" would have fixed numerous bugs that I dealt with in UI land regarding state and dealing with changing state. Developer happiness is worth a lot when the project is open-source, unfunded, and done by someone with passion (which is how almost all open source starts).
4. I think it's temporary. There's projects like Proton that are already looking at how to get the best of React/JS on the desktop without the bloat of shipping a web browser with your app. The future looks bright.
NOTE for people devving on electron: Please be more conscious of memory usage and potential memory leaks. Desktop apps are often long-running and you've got to pay attention to resource usage and the memory leak traps that can cause your app to gobble up insane amounts of memory (cough slack cough)
1. It enables a large swatch of people that have never done desktop development (which has a learning curve that is hard to climb if you aren't paid to do it) to build cool stuff and ship it. Without Electron, we'd be left with nothing. If nothing is truly better than something with Electron, then this won't be a compelling point. However I'd rather have stuff that I ignore than to not have stuff.
2. Performance in electron can be decent. It isn't always because of bloat and poor implementation, but that can be true of native apps as well (especially java-based ones). The download size is laughable, but hard drives are reasonably sized these days so this is less of a pragmatic concern, and more of an ideological purity concern.
3. The modern paradigm that React brings to the table can genuinely be a better dev experience than the traditional frameworks. The benefits of "always re-render" would have fixed numerous bugs that I dealt with in UI land regarding state and dealing with changing state. Developer happiness is worth a lot when the project is open-source, unfunded, and done by someone with passion (which is how almost all open source starts).
4. I think it's temporary. There's projects like Proton that are already looking at how to get the best of React/JS on the desktop without the bloat of shipping a web browser with your app. The future looks bright.
NOTE for people devving on electron: Please be more conscious of memory usage and potential memory leaks. Desktop apps are often long-running and you've got to pay attention to resource usage and the memory leak traps that can cause your app to gobble up insane amounts of memory (cough slack cough)
Thanks for these! Proton is interesting, I think the space has a lot of potential.
I'm concerned that someday html might be the standard for gui system markups, that could go wrong easily.
Part of my perspective on this, maybe yours as well, is the amount of projects in electron that just didn't need to exist in the first place. Guys writing email clients, for example. Nobody is going to use something like that. Casual users will prefer the browser and power users need mega-apps like Thunderbird to be productive enough.
I've been hoping Elm guy would try and bring Elm to Qt or OpenGL or something like that. I think desktop apps have a lot to learn from FRP, which is prevalent in web tech, or at least more so than it has been in the past.
It almost reminds me of Emacs, ya know? Everything and the kitchen sink, and the plumber, and his truck, and the Home Depot. Unnecessary!
Anyways thanks for your comments. Your experience is helpful!
I'm concerned that someday html might be the standard for gui system markups, that could go wrong easily.
Part of my perspective on this, maybe yours as well, is the amount of projects in electron that just didn't need to exist in the first place. Guys writing email clients, for example. Nobody is going to use something like that. Casual users will prefer the browser and power users need mega-apps like Thunderbird to be productive enough.
I've been hoping Elm guy would try and bring Elm to Qt or OpenGL or something like that. I think desktop apps have a lot to learn from FRP, which is prevalent in web tech, or at least more so than it has been in the past.
It almost reminds me of Emacs, ya know? Everything and the kitchen sink, and the plumber, and his truck, and the Home Depot. Unnecessary!
Anyways thanks for your comments. Your experience is helpful!
Definitely, and thank you for your perspective! I totally agree WRT FRP. I have a friend that swears by FRP on Android. I believe he uses RxJava and RxKotlin.
Something like Elm coming to Qt would be great!
Something like Elm coming to Qt would be great!
Apart from VSCode, I'm also not a fan of Electron - but I do understand why people use it.
> When GTK and Qt both provide js api capabilities, what else is there to gain?
It's the HTML5. How would you write an xplat editor with GTK or QT? The obvious answer is to use Scintilla and after some Googling surrounding getting that right, you're successful! Now you want to start innovating the editor, with both the speed and bravery that the VSCode team do. Now you have problems.
As much as I despise HTML5, it does provide a canvas that behaves consistently across platforms (so long as your browser is consistent, which Electron is). I can't see why you'd use it for a music app or so forth, but rendering a text editor is a surprisingly difficult task - it does present genuine benefit in this field.
You could use OpenGL or Vulkan, but then you'd spend your life writing the UI framework and wouldn't have the xplat layer that NodeJS offers.
> When GTK and Qt both provide js api capabilities, what else is there to gain?
It's the HTML5. How would you write an xplat editor with GTK or QT? The obvious answer is to use Scintilla and after some Googling surrounding getting that right, you're successful! Now you want to start innovating the editor, with both the speed and bravery that the VSCode team do. Now you have problems.
As much as I despise HTML5, it does provide a canvas that behaves consistently across platforms (so long as your browser is consistent, which Electron is). I can't see why you'd use it for a music app or so forth, but rendering a text editor is a surprisingly difficult task - it does present genuine benefit in this field.
You could use OpenGL or Vulkan, but then you'd spend your life writing the UI framework and wouldn't have the xplat layer that NodeJS offers.
So what electron developers appreciate is an easily accessible markup+canvas?
Text editors are a great example, they're very difficult to get right.
I wonder why more desktop GUI platforms aren't equipped with something similar to html5->native markup.
Thanks for your comment, that clears up the question of appeal for me a bit. I can see how much frustration is saved in a project like vscode by using electron.
Text editors are a great example, they're very difficult to get right.
I wonder why more desktop GUI platforms aren't equipped with something similar to html5->native markup.
Thanks for your comment, that clears up the question of appeal for me a bit. I can see how much frustration is saved in a project like vscode by using electron.
> html5->native markup.
I'm personally a bigger fan of XAML (done right, with MVVM) for that purpose, but it's unrealistic because XAML is dead. So ultimately I agree, there should be a browser of sorts for highly trusted apps. Electron is a runtime, it shouldn't be bundled with every app that uses it.
I'm personally a bigger fan of XAML (done right, with MVVM) for that purpose, but it's unrealistic because XAML is dead. So ultimately I agree, there should be a browser of sorts for highly trusted apps. Electron is a runtime, it shouldn't be bundled with every app that uses it.
Maybe I should tell that to the guys that have paid my bills for the last 4 years.
I've programmed in Electron and GTK (about 8 years ago), so can only compare those two.
GTK claims to be cross platform, but the windows support is (at least was), awful. Lots of special casing required. Also hi dpi screens never worked right. Also just getting tge dev environment configured on mac, windows and linux was a multi day undertakung and required weird dodgy mingw gcc builds.
With electron, the multi platform is taken seriously. It just works. Also, because electron doesnt try to look like each OS's default toolkit, your app looks the same in all 3 major OSes, so you dont need piles of os specific GUI fine tuning code.
GTK claims to be cross platform, but the windows support is (at least was), awful. Lots of special casing required. Also hi dpi screens never worked right. Also just getting tge dev environment configured on mac, windows and linux was a multi day undertakung and required weird dodgy mingw gcc builds.
With electron, the multi platform is taken seriously. It just works. Also, because electron doesnt try to look like each OS's default toolkit, your app looks the same in all 3 major OSes, so you dont need piles of os specific GUI fine tuning code.
> because electron doesnt try to look like each OS's default toolkit, your app looks the same in all 3 major OSes
That's a significant selling point actually. When I did Qt and also Swing, this was something that got me often. Making something look just right with polish gets to be quite difficult without having tons of platform specific code and logic.
That's a significant selling point actually. When I did Qt and also Swing, this was something that got me often. Making something look just right with polish gets to be quite difficult without having tons of platform specific code and logic.
Because most cross-platform desktop GUI kits are terrible. Everything that's not paid requires a lot of fiddling with C++ bindings and obscure build scripts. Electron is built on Chrome which has billions of dollars backing it. If you want something that's easy to use (and not having to spend too much time thinking about license compliance), looks pretty and works well, your options are pretty limited. Say what you must about Google and profiting from ads but electron is one of the only few full-featured GUI frameworks that allows for simple statically linked app distribution. For free.
I will repost my comment from the last time this was on the front page. Hopefully it's more constructive than "electron sux lol":
I've been using Oni for the last few weeks as my daily driver (I liked it so much I signed up as a monthly sponsor), and here's my take on it:
It's a fairly new project, but it's under _very_ active development. There's an excellent community building around it and I think we will be seeing some really great progress over the next year. That said, it isn't anywhere close to feature parity with vscode, but the value proposition is: neovim, with vscode compatible snippets and typescript-language-server-driven autocomplete (also works with vanilla JS) out of the box. AFAIK it works with any language language server with a few lines of configuration. I have tried several times to get You Complete Me working to my satisfaction and never quite got there despite spending several weekends working on it. Oni just works.
The bonus value proposition is: since it is a GUI wrapper around neovim, you get to retain all of the muscle memory you have built up in your years of using vim, but potentially also get many of the goodies that a graphical IDE like vscode provides. I have tried the vscode vim extensions, and they are really impressive, but they are still limited by the vscode extension api and at the end of the day it's not a real vim. For me, it was just not-vimish enough to constantly interrupt my flow; I believe the original inspiration for Oni was the creator's frustrations with vscode vim extensions.
I have been digging into the development process and I've been _really_ impressed with how brilliant and industrious the main contributors are; features are getting added at a breakneck pace. A few things that are in the works: real-time browser pane with auto-refresh (I just tried out the browser feature and it works like it's just another vim buffer... pretty awesome stuff!), markdown preview, a gamified tutor mode for newbies, and a webgl renderer that is about 10x faster in benchmarks than the canvas renderer.
I've been using Oni for the last few weeks as my daily driver (I liked it so much I signed up as a monthly sponsor), and here's my take on it:
It's a fairly new project, but it's under _very_ active development. There's an excellent community building around it and I think we will be seeing some really great progress over the next year. That said, it isn't anywhere close to feature parity with vscode, but the value proposition is: neovim, with vscode compatible snippets and typescript-language-server-driven autocomplete (also works with vanilla JS) out of the box. AFAIK it works with any language language server with a few lines of configuration. I have tried several times to get You Complete Me working to my satisfaction and never quite got there despite spending several weekends working on it. Oni just works.
The bonus value proposition is: since it is a GUI wrapper around neovim, you get to retain all of the muscle memory you have built up in your years of using vim, but potentially also get many of the goodies that a graphical IDE like vscode provides. I have tried the vscode vim extensions, and they are really impressive, but they are still limited by the vscode extension api and at the end of the day it's not a real vim. For me, it was just not-vimish enough to constantly interrupt my flow; I believe the original inspiration for Oni was the creator's frustrations with vscode vim extensions.
I have been digging into the development process and I've been _really_ impressed with how brilliant and industrious the main contributors are; features are getting added at a breakneck pace. A few things that are in the works: real-time browser pane with auto-refresh (I just tried out the browser feature and it works like it's just another vim buffer... pretty awesome stuff!), markdown preview, a gamified tutor mode for newbies, and a webgl renderer that is about 10x faster in benchmarks than the canvas renderer.
It stops a lot of people from using VS Code and Atom. I already dislike that I need to use other Electron based apps for other reasons, and I'm certainly not going to add to the amount I have to run if I can help it.
I think the hope is if we keep going "Electron isn't a great idea, there are a lot of drawbacks, please stop", people will actually stop.
I think the hope is if we keep going "Electron isn't a great idea, there are a lot of drawbacks, please stop", people will actually stop.
[deleted]
[deleted]
Yeah, I totally agree. I use VSCode and I'm happy with it. Electron apps are slower, but not to the extent that I won't use Electron based apps. Personally, I'm excited to try out Oni.
> I hate these posts, because Hacker News is incapable of talking about an Electron based project productively.
Oni maintainer here! I agree - I get stressed out sometimes when this gets posted to HN for that reason ;)
I'll piggyback here because this is near the top, but I'll give a couple quick reasons why Electron was chosen for this project:
- Development speed As mentioned in another comment, the React ecosystem has some excellent development tools around hot-reloading / live-reloading. I never found this sort of 'live-reload' workflow in any of the C/C++ toolchains I've used. (Would be interested if that has changed!)
For a very small team, this is an important consideration! It's the difference between Oni existing as an Electron app vs. not existing at all.
- Developers Oni is an open source project, and I open-sourced it because I wanted help building it (and I've been fortunate to work with some amazing contributors [1]). When you look at the last StackOverflow Developer Survey [2], web tech is overwhelmingly at the top - if I want help, I should pick the tech stack that has the broadest appeal.
Every editor is an exercise in trade-offs, and of course Electron brings trade-offs of its own. Oni is an experiment in a different (not necessarily better, because that's subjective and relative to each person's workflow) set of trade-offs than other editors - an attempt to bring together the "modern" functionality of editors like Code/Atom with Vim. It resonates with some people, but it's not going to be for everyone, and that's OK.
Even if you don't use Oni or agree with the tech stack, these sorts of experiments are important, because if new ideas or workflows work well... they can find their way into your editor of choice, too.
One other note - I focused a lot on Electron, but the project wouldn't be here without neovim, either! They've done excellent work, and there is quite a variety of front-ends - so even if Oni isn't your thing, I'd encourage to check out that project as well as some of the front-ends for it [3].
[1] - https://github.com/onivim/oni/graphs/contributors
[2] - https://insights.stackoverflow.com/survey/2018/#technology
[3] - https://github.com/neovim/neovim/wiki/Related-projects
Oni maintainer here! I agree - I get stressed out sometimes when this gets posted to HN for that reason ;)
I'll piggyback here because this is near the top, but I'll give a couple quick reasons why Electron was chosen for this project:
- Development speed As mentioned in another comment, the React ecosystem has some excellent development tools around hot-reloading / live-reloading. I never found this sort of 'live-reload' workflow in any of the C/C++ toolchains I've used. (Would be interested if that has changed!)
For a very small team, this is an important consideration! It's the difference between Oni existing as an Electron app vs. not existing at all.
- Developers Oni is an open source project, and I open-sourced it because I wanted help building it (and I've been fortunate to work with some amazing contributors [1]). When you look at the last StackOverflow Developer Survey [2], web tech is overwhelmingly at the top - if I want help, I should pick the tech stack that has the broadest appeal.
Every editor is an exercise in trade-offs, and of course Electron brings trade-offs of its own. Oni is an experiment in a different (not necessarily better, because that's subjective and relative to each person's workflow) set of trade-offs than other editors - an attempt to bring together the "modern" functionality of editors like Code/Atom with Vim. It resonates with some people, but it's not going to be for everyone, and that's OK.
Even if you don't use Oni or agree with the tech stack, these sorts of experiments are important, because if new ideas or workflows work well... they can find their way into your editor of choice, too.
One other note - I focused a lot on Electron, but the project wouldn't be here without neovim, either! They've done excellent work, and there is quite a variety of front-ends - so even if Oni isn't your thing, I'd encourage to check out that project as well as some of the front-ends for it [3].
[1] - https://github.com/onivim/oni/graphs/contributors
[2] - https://insights.stackoverflow.com/survey/2018/#technology
[3] - https://github.com/neovim/neovim/wiki/Related-projects
[deleted]
Oni is Electron based. But since it uses neovim as its backend and a canvas based renderer the performance is actually very good.
There's a webgl renderer behind an experimental flag that is about 10x faster than the canvas renderer :)
Wow, that's awesome. Honestly vanilla vim is often not that performant due to limitations of how terminals work. I wouldn't be surprised if OpenGL onivim could outperform terminal vim in a lot of scenarios. How does it compare to gvim's performance?
I haven't compared it to gvim, but gvim seems like it would have the upper hand there since it is native. There's also the fact that no matter how fast the renderer is, it can never be faster than the neovim instance running under the hood. I do not have any detailed knowledge of the internals though, so I could be wrong.
The best of Vim and any combination of other editors is still just Vim.
[deleted]
I'm very interested in the idea, but unfortunately it was way too laggy for me. Noticeable lag just moving the cursor around prevented me from taking a deeper look.
EDIT: the title used to be "oni: better than vim, atom and VSCode".
It seems the title comes from the submitter here, rather than the web page.
I've looked at this, and as a VSCode user, it is not at all a useful replacement, it's barely usable for me. Also VSCode has a lots of useful plugins, which aren't support here.
I'm sure if I learnt all the vim shortcuts it would be great but then I'm using VSCode because I don't like vim.
It seems the title comes from the submitter here, rather than the web page.
I've looked at this, and as a VSCode user, it is not at all a useful replacement, it's barely usable for me. Also VSCode has a lots of useful plugins, which aren't support here.
I'm sure if I learnt all the vim shortcuts it would be great but then I'm using VSCode because I don't like vim.
To respond to this and the child comment, since Oni is a wrapper that communicates with an actual neovim process, most (neo)vim plugins should be useable with Oni. I've had great success simply telling Oni to read my existing init.vim (that I use with neovim in regular terminals) and my 20+ plugins just working.
Whether or not Oni provides additional utility over a standard (neo)vim in a terminal is probably dependent on personal preference. There is also definitely a cost to the use of Electron, I typically have 4 or 5 windows running at a time, one for each project I work on, and it uses about a GB of RAM in total, so if you're on a memory-tight system you may not want to stick with terminal vim.
Whether or not Oni provides additional utility over a standard (neo)vim in a terminal is probably dependent on personal preference. There is also definitely a cost to the use of Electron, I typically have 4 or 5 windows running at a time, one for each project I work on, and it uses about a GB of RAM in total, so if you're on a memory-tight system you may not want to stick with terminal vim.
This is exactly why I moved from Oni to VSCode with neovim embedded.
Oni was just way too slow and i couldn't use the plugins i needed from my previous vim setup. I switched to VSCode and now I get best of both worlds!
Oni was just way too slow and i couldn't use the plugins i needed from my previous vim setup. I switched to VSCode and now I get best of both worlds!
I like Oni but last time (a week ago) I tried it I went into the config file to change the colourscheme and the doc wasn't helpful at all. I think it somehow can take a vim config file but it wasn't really clear.
There's a decent wiki article on the configuration file: https://github.com/onivim/oni/wiki/Configuration
I use "oni.useDefaultConfig": false and "oni.loadInitVim": true and use it basically the same way I use terminal vim, but with language server autocomplete thrown in for free.
I use "oni.useDefaultConfig": false and "oni.loadInitVim": true and use it basically the same way I use terminal vim, but with language server autocomplete thrown in for free.
I tried Oni, but it fundamentally doesn't understand buffers.
[deleted]
Yeah you can go ahead and miss me with every single one of these vim-via-Electron monstrosities.
CLARIFICATION: For me the whole point of learning vim was that it's lightweight and ubiquitous. Stuff like this is 0 out of 2 on that front.
CLARIFICATION: For me the whole point of learning vim was that it's lightweight and ubiquitous. Stuff like this is 0 out of 2 on that front.
I think one of the points that this and some of the other comments may be missing is that this isn't electron with vim keybindings, it's an electron gui for a real (neo)vim process running in the background. All your standard vim features are there. A user only familiar with Oni shouldn't have much trouble using a standard vim install.
There's definitely an argument to be made that Oni may not add much over running vim in a terminal, especially given the increased resource requirements inherent to electron, and I'd certainly like to see a high performance cross platform neovim gui that doesn't use electron, but I think Oni at least delivers a very useful experience on its own by building on top of all the work already invested into vim.
There's definitely an argument to be made that Oni may not add much over running vim in a terminal, especially given the increased resource requirements inherent to electron, and I'd certainly like to see a high performance cross platform neovim gui that doesn't use electron, but I think Oni at least delivers a very useful experience on its own by building on top of all the work already invested into vim.
I use Vim and Vim keybindings for other editors. I learned Vim because like you say, it’s lightweight and ubiquitous. But for some larger scale projects I need the power of a full IDE. So then I use for example PyCharm with Vim keybindings.
As long as the Vim emulation is good you are still using the same “skills”.
In the case of the OP it’s a frontend to neovim even, so it’s not even just a partial emulation, it’s the real deal.
That being said I tried Oni a few weeks ago because I thought it would bring me something but I found no immediate advantage so I didn’t bother to keep using it.
As long as the Vim emulation is good you are still using the same “skills”.
In the case of the OP it’s a frontend to neovim even, so it’s not even just a partial emulation, it’s the real deal.
That being said I tried Oni a few weeks ago because I thought it would bring me something but I found no immediate advantage so I didn’t bother to keep using it.
Right, I can fire up vim on pretty much any old server out there and get a familiar editor. It may not have my vimrc and may not have a few plugins that I like, but none of that is crippling if you learn to appreciate and use vanilla vim and even vi.
That said, if you're doing almost all your work from your local machine, these editors probably serve a valuable purpose still.
That said, if you're doing almost all your work from your local machine, these editors probably serve a valuable purpose still.
> if you're doing almost all your work from your local machine
Lol, this is most people, and also the target audience of this application. Note that it doesn't claim to be a VIM replacement, just a modal editor for the desktop that's based on it.
Lol, this is most people, and also the target audience of this application. Note that it doesn't claim to be a VIM replacement, just a modal editor for the desktop that's based on it.
[deleted]
[deleted]
Yeah one of the major points towards vim is pretty much every unix environment has vim installed.
Actually if you happen to ssh into the classical proprietary UNIX servers you might end up with plain old vi still.
But yeah, that is why even I as Emacs user always bothered to at least know my way around vi, usually Emacs is most likely not installed.
But yeah, that is why even I as Emacs user always bothered to at least know my way around vi, usually Emacs is most likely not installed.
> Actually if you happen to ssh into the classical proprietary UNIX servers you might end up with plain old vi still.
Let's be honest: out of 10000000000's of SSH connections in a given 24 hours span, how many are to a "classical proprietary UNIX server"? 0.0001% maybe ? Is it really a use case worth optimizing for ? They should be treated as applicances, not as general-purpose computers.
Let's be honest: out of 10000000000's of SSH connections in a given 24 hours span, how many are to a "classical proprietary UNIX server"? 0.0001% maybe ? Is it really a use case worth optimizing for ? They should be treated as applicances, not as general-purpose computers.
Depends on where you work. It could easily be 100% of the ssh connections you make.
I'd add that if you have more than a handful of servers, and find yourself shelling into these and editing files by hand regularly, you're doing ops wrong
The kind of companies where budgets for Oracle and DB2 licenses are rounding errors.
As sibling noted, it depends on where you work. I've seen AIX and Solaris still in use.
Oni is basically a vim ide with vim tutorials included.
it's trying to decrease the vim learning curve.
Product might not be for you.
Product might not be for you.
On that note, I'm still waiting on a lightweight vim clone with a sane plugin/command system.
I'm glad everyone likes vim as an editing style. I do to and would prefer to use vim, however I was able to get VS Code configured with plugins how I want to work in a matter of minutes, as opposed to wasting days upon days (over my life probably a solid month) trying to get a sane vim config that works with my languages and tools.
I'm glad everyone likes vim as an editing style. I do to and would prefer to use vim, however I was able to get VS Code configured with plugins how I want to work in a matter of minutes, as opposed to wasting days upon days (over my life probably a solid month) trying to get a sane vim config that works with my languages and tools.
Have you tried spacevim? https://spacevim.org/
[deleted]
Amen.
Anecdote: be on Windows. Need text editor to open 100MB file. Notepad sucks. Wordpad actually loads the file, but I just can't. Think about getting Notepad++. Decide to try out Atom because the UX looks nice. It can't load the file; have to kill the process. Install Emacs. Just works.
These things are cool for your portfolio, but they are less effective than 40 year old alternatives.
Anecdote: be on Windows. Need text editor to open 100MB file. Notepad sucks. Wordpad actually loads the file, but I just can't. Think about getting Notepad++. Decide to try out Atom because the UX looks nice. It can't load the file; have to kill the process. Install Emacs. Just works.
These things are cool for your portfolio, but they are less effective than 40 year old alternatives.
Yeah, in some situations those oldschool tools are just much more capable than their modern counterparts. Never had any filesize problems with sed and dd :D
I find myself using the mouse all the time, and I don't understand this obsession with mouse-less text editing. The mouse lets me perform selections, and with some key-combos in sublime text sets me up for multiple cursor editing very nicely, in ways that would be much much more complex if I were trying to do them in vim.
I've always wanted to try out Acme, a mouse-first editor from plan nine, with all of this obsession with cutting the mouse out entirely, it feels like there is space for an editor to really consider what the mouse can be used for.