Oni: An IDE powered by Neovim(github.com)
github.com
Oni: An IDE powered by Neovim
https://github.com/extr0py/oni
111 comments
"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?
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?
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.
Blizzard's battle.net client is a qt app. I don't think it's available on linux though.
> I don't think it's available on linux though.
https://appdb.winehq.org/objectManager.php?sClass=version&iI...
Yes, feels strange to think that you need to run a qt app against wine because the publisher does not support gnu/linux.
But it is available on linux via `apt install wine` and downloading the exe.
https://appdb.winehq.org/objectManager.php?sClass=version&iI...
Yes, feels strange to think that you need to run a qt app against wine because the publisher does not support gnu/linux.
But it is available on linux via `apt install wine` and downloading the exe.
"What Qt application has as much reach as slack?"
- KDE
- AMD's Radeon control panel
- VLC
- VirtualBox
Qt apps feel far more native than Electron apps in my opinion.
- KDE
- AMD's Radeon control panel
- VLC
- VirtualBox
Qt apps feel far more native than Electron apps in my opinion.
KDE: not at all comparable to Slack's reach. Not an app. Not even cross-platform?
AMD's Radeon: admittedly, I have not used this.
VLC: hardly any UI. Mostly menu items.
VirtualBox: hardly any UI. Mostly menu items.
Edit: formatting.
AMD's Radeon: admittedly, I have not used this.
VLC: hardly any UI. Mostly menu items.
VirtualBox: hardly any UI. Mostly menu items.
Edit: formatting.
I've used the Radeon control panel. I also use the Slack and Spotify apps all the time with no complaints.
The Radeon interface does not fit in at all with Windows (nor macOS or any Linux DE I've ever seen, for that matter) and is almost always glitchy for me.
The Radeon interface does not fit in at all with Windows (nor macOS or any Linux DE I've ever seen, for that matter) and is almost always glitchy for me.
The Radeon control panel is worse than any electron app I have used, often glitching/freezing.
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.
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.
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.
Man, do I hate comments like these. Drive me nuts. I'd comment with my real username but I'm on travels on a public terminal.
"Favors developer user experience over end-user experience"
So, something that favors end-user experience over developer experience will produce spanking fantastic apps?
"It's like shitty IOS cordova.."
Like shitty android/ios apps without the cross-platform functionality?
"Are you really ignorant?"
Holy crap! Most of us here know the stuff from the 80's! We also know the awesome stuff we can do with modern tech.
Your comment sucks of classic cargo cow bullshit. Loosen up.
"Favors developer user experience over end-user experience"
So, something that favors end-user experience over developer experience will produce spanking fantastic apps?
"It's like shitty IOS cordova.."
Like shitty android/ios apps without the cross-platform functionality?
"Are you really ignorant?"
Holy crap! Most of us here know the stuff from the 80's! We also know the awesome stuff we can do with modern tech.
Your comment sucks of classic cargo cow bullshit. Loosen up.
Note that I don't prefer one technology over the other here, I just pointed out that this seems to be why people pick Electron.
I already know of the toolkits you mentioned, no need to call me ignorant. I have to admit I've never seen a single Qt, SWT, GTK app that looked and felt native. There probably are some but I would argue the effort is much higher than Electron.
I already know of the toolkits you mentioned, no need to call me ignorant. I have to admit I've never seen a single Qt, SWT, GTK app that looked and felt native. There probably are some but I would argue the effort is much higher than Electron.
Interestingly, I'm an end user of both Visual Studio and Visual Studio Code on a daily basis, and far prefer the user experience of the latter, Electron or no.
In my opinion, the primary driver for Electron is the Javascript runtime. Lots of people have Javascript experience and Electron makes it easy to use that knowledge to bang out a desktop-like application. The write once, run anywhere angle is compelling as well but that's how web browsers and Javascript work; sure Electron gets to enjoy this but it's a function of this technology stack.
I disagree that the comments pointing out the high CPU and memory usage are non-constructive. These are real issues that literally limit the number of Electron apps that can run at a time on a particular machine. Some Electron apps perform reasonably well, VS Code is a good example. But many perform abysmally and Electron is treading dangerous ground by going against the trend of limiting resource usage in order to extend battery life. Indeed, in my experience running a handful of Electron apps is a sure way to shorten battery life.
I think that "Something like Electron but native" is a confusing idea. The browser engine that Electron uses is native to the OS it's running on... As others have pointed out, the best we could hope for is some sharing of the runtime that would allow more applications to run simultaneously.
You mention native languages that have a good cross platform story and I'd like to see some work toward a UI toolkit that is less demanding of resources. While people like Javascript, I do believe some of them will move to another language if they can do what they need to do: deploy to all OS environments with only minimal code changes. If Electron has taught us anything, it's that customer's don't really care that much about an application appearing to be "native".
I disagree that the comments pointing out the high CPU and memory usage are non-constructive. These are real issues that literally limit the number of Electron apps that can run at a time on a particular machine. Some Electron apps perform reasonably well, VS Code is a good example. But many perform abysmally and Electron is treading dangerous ground by going against the trend of limiting resource usage in order to extend battery life. Indeed, in my experience running a handful of Electron apps is a sure way to shorten battery life.
I think that "Something like Electron but native" is a confusing idea. The browser engine that Electron uses is native to the OS it's running on... As others have pointed out, the best we could hope for is some sharing of the runtime that would allow more applications to run simultaneously.
You mention native languages that have a good cross platform story and I'd like to see some work toward a UI toolkit that is less demanding of resources. While people like Javascript, I do believe some of them will move to another language if they can do what they need to do: deploy to all OS environments with only minimal code changes. If Electron has taught us anything, it's that customer's don't really care that much about an application appearing to be "native".
I think you're right on many points, and I was more referring to the posts just complaining about it being in Electron at all as if Electron was some kind of bad word which should immediately trigger dismissal.
> I think that "Something like Electron but native" is a confusing idea. The browser engine that Electron uses is native to the OS it's running on...
Here I meant native as in a natively compiled language. The browser is also invisible in this case, and the whole Electron model adds so many layers (which is part of the resource usage problem).
> If Electron has taught us anything, it's that customer's don't really care that much about an application appearing to be "native".
In this case I meant native as in blending in with the desktop environment, which I think Electron apps are more successful at than other toolkits (which are often natively compiled).
> I think that "Something like Electron but native" is a confusing idea. The browser engine that Electron uses is native to the OS it's running on...
Here I meant native as in a natively compiled language. The browser is also invisible in this case, and the whole Electron model adds so many layers (which is part of the resource usage problem).
> If Electron has taught us anything, it's that customer's don't really care that much about an application appearing to be "native".
In this case I meant native as in blending in with the desktop environment, which I think Electron apps are more successful at than other toolkits (which are often natively compiled).
I find the appearance of Electron applications pleasing, I am not trying to take a crack at Electron when I say this: I don't think they are particularly native looking and I think this is an advantage to Electron. The point I was trying to make is that I don't think "looking native" is all that important anymore. Web applications seem to have trained people away from that "I can only click on things that look like buttons" straight-jacket.
[deleted]
There's React Native, which has unofficial bindings for different desktop environments.
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.)
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.)
The users matter, not the contributors.
> Can't really think of writing all this up in plain C++, wiring up native calls...
Yes, it's more work and features will come slower, but the end result is a better application. Latency matters. It's extremely irritating that when I hold the delete key in an electron based application like visual studio code, that half my file continues to be deleted after I let go of the key. The application can't keep up with the key repeat speed, and it's running on a high end workstation! It's pathetically slow, even for all of the improvements that have been made over others like atom and brackets.
I'm excited by Oni, and it saddens me that the top comment is a negative comment complaining we should all just support electron.
> Can't really think of writing all this up in plain C++, wiring up native calls...
Yes, it's more work and features will come slower, but the end result is a better application. Latency matters. It's extremely irritating that when I hold the delete key in an electron based application like visual studio code, that half my file continues to be deleted after I let go of the key. The application can't keep up with the key repeat speed, and it's running on a high end workstation! It's pathetically slow, even for all of the improvements that have been made over others like atom and brackets.
I'm excited by Oni, and it saddens me that the top comment is a negative comment complaining we should all just support electron.
You're both right. The best thing for the Oni dev to do now (presuming your performance comments apply directly to it) is to go back and identify/fix the cause of the performance issues. If the performance improvements can be done in the Electron code itself then we get the best of both worlds.
I think there's misunderstanding here, because I don't think that electron is the only way to go. Like the author of oni wrote here, we can make this frontend happen on any web-friendly runtime.
What I mean is that we should put aside the cons brought by a piece of building block and appreciate the vision, and the ideas behind these "new old things" -- neovim, oni, etc., to which we have been on the same page. However, discussion about whether it's appropriate to use Electron in this thread, without technical explanation or a proposal for workarounds, are distractions in my opinion.
What I mean is that we should put aside the cons brought by a piece of building block and appreciate the vision, and the ideas behind these "new old things" -- neovim, oni, etc., to which we have been on the same page. However, discussion about whether it's appropriate to use Electron in this thread, without technical explanation or a proposal for workarounds, are distractions in my opinion.
> Once upon a time there was Qt, but now it's also doing qml+js..
QML+JS is still primarily C++ in that the QML gets compiled into a scene graph that is then processed in C++ and OpenGL and your JS would typically only be setup and glue code. QML makes it super easy to write single objects in C++ and have them seamlessly communicate with QML/JS, so writing simple logic in JS and performance-sensitive code in C++ is easy to do. QML performs extremely well, while my brief experience with electron was less favourable.
QML+JS is still primarily C++ in that the QML gets compiled into a scene graph that is then processed in C++ and OpenGL and your JS would typically only be setup and glue code. QML makes it super easy to write single objects in C++ and have them seamlessly communicate with QML/JS, so writing simple logic in JS and performance-sensitive code in C++ is easy to do. QML performs extremely well, while my brief experience with electron was less favourable.
I'd agree with you on the basic idea, but practically from my experience, the qml+js subsystem seems like an isolated piece of "glueware" upon a legacy platform and they do not interpolate very well. Once I did a knowledge graph representation with the css-like qml goodies. I felt good about it because I cranked it up really fast. But later when I want to implement a force-based layout algorithm I found myself forced to implement it in Javascript, because the interop is both slow and cumbersome. So it's not like we have the javascript host and a bunch of native extensions, but rather, a floating js runtime, plugged into the great Qt4 legacy, with the two sides communicating through narrow gates...
QtQucik isn't a legacy platform, its been developed from ground up and only shares the data structures (QObject, QVariant, QVector etc... but it works pretty well with C++ Standard Library too) with the legacy QWidgets stuff.
> I found myself forced to implement it in Javascript, because the interop is both slow and cumbersome
I'm a bit confused by this because its different from my personal experience, where implementing custom QObjects was both developer-friendly (easy and quick to accomplish) and performant. I guess your experience was different. Would love to hear a bit more about your use case and why it didn't work for you.
> plugged into the great Qt4 legacy
Beyond the basic classes like QObject/QVariant/QVector and some of the addon libraries like QtConcurrent, when I used QtQuick/QML, I didn't have to use any of the Qt4 legacy stuff and had a pretty slick experience of developing UI in QML, glue in JS and any heavy lifting or platform interpo in C++ as custom QObjectf. Since C++11, its also been even slicker because they made most of the Qt Library classes interoperate with C++11 better (especially allowing you to connect lambda's directly to signals).
I wonder why you had such a different experience than I did? Although, to be fair, I haven't done any serious Qt work in ~2 years or perhaps a little more, so maybe my experience isn't representative (I used it to do the UI for a data analysis tool, it was performance sensitive but not THAAAAT much, so maybe if it had been more so it would have been problematic?)
Would love to hear more about what problems you faced!
> I found myself forced to implement it in Javascript, because the interop is both slow and cumbersome
I'm a bit confused by this because its different from my personal experience, where implementing custom QObjects was both developer-friendly (easy and quick to accomplish) and performant. I guess your experience was different. Would love to hear a bit more about your use case and why it didn't work for you.
> plugged into the great Qt4 legacy
Beyond the basic classes like QObject/QVariant/QVector and some of the addon libraries like QtConcurrent, when I used QtQuick/QML, I didn't have to use any of the Qt4 legacy stuff and had a pretty slick experience of developing UI in QML, glue in JS and any heavy lifting or platform interpo in C++ as custom QObjectf. Since C++11, its also been even slicker because they made most of the Qt Library classes interoperate with C++11 better (especially allowing you to connect lambda's directly to signals).
I wonder why you had such a different experience than I did? Although, to be fair, I haven't done any serious Qt work in ~2 years or perhaps a little more, so maybe my experience isn't representative (I used it to do the UI for a data analysis tool, it was performance sensitive but not THAAAAT much, so maybe if it had been more so it would have been problematic?)
Would love to hear more about what problems you faced!
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.
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
Edit spelling
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.
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.
> The problem is that, just like Java, electron wins at the end of the day in terms of market share.
The hell are you talking about, Electron still doesn't come near the marketshare when you look at acual apps using other cross-platform GUI toolkits.
The hell are you talking about, Electron still doesn't come near the marketshare when you look at acual apps using other cross-platform GUI toolkits.
I don't think Java ever "won" in the cross-platform GUI application space. Sun tried hard and Swing was successful in terms of being able to produce a reliable, cross-platform experience that was reasonable. But in terms of developer mind-share and actual applications on the desktop, I'd say it's success was pretty meager. Aside from IntelliJ and NetBeans and Eclipse (yep, I know, SWT) I'm hard pressed to think of other popular Java GUI applications.
I really like the idea of React Native... similar JS engine constructs, but a leaner UI layer... though, really need a bit more unity in UI controls across platforms.
Another bit seems to be some work in progress from the Xamarin guys at MS.
In the end, an XML based UI combined with a JS runtime engine seems to be a very powerful combination... getting similar points of integration with other languages could be equally nice.
Something resembling Material Design, or Bootstrap as a cross platform UI toolkit with an XML interface would be a great place to start. Electron really seems to be as close as it gets for the most part, with the least cross platform effort.
Another bit seems to be some work in progress from the Xamarin guys at MS.
In the end, an XML based UI combined with a JS runtime engine seems to be a very powerful combination... getting similar points of integration with other languages could be equally nice.
Something resembling Material Design, or Bootstrap as a cross platform UI toolkit with an XML interface would be a great place to start. Electron really seems to be as close as it gets for the most part, with the least cross platform effort.
The deeply flawed framework being HTML/CSS, JS, Node.js, or all of the above?
> I think Electron is a very cost efficient dev environment.
Because it's faster to develop? You're basically trading developer time with user time and battery life.
> Can't really think of writing all this up in plain C++
IntelliJ is written in Java.
Because it's faster to develop? You're basically trading developer time with user time and battery life.
> Can't really think of writing all this up in plain C++
IntelliJ is written in Java.
For which reason I refuse to run Electron applications. My battery life is poor enough as it is.
Author here - thanks for the kind words! Yes, your comment hits the nail on the head and echoes my thoughts exactly. Electron happens to be a great way to test out some of the thoughts and I ideas in an economical way - especially since my time to work on Oni is limited at the moment.
And I think the fat headroom for improvements is important to call out - when people talk about "Electron Bloat", they usually refer to one of 5 things:
1) Footprint (space on disk) 2) Memory usage 3) CPU usage (corresponding to battery life) 4) Responsiveness (esp typing latency) 5) Startup time
As you mentioned, across the board, there's a bunch of room for improvements - especially with tech like WebAssembly on the horizon! #1 and #2 are the hardest, because Electron will always have a fixed overhead - but when comparing to an IDE like Visual Studio, it's not over the top.
For my workflow, #4, #5, and #3 are most important, and Oni still has plenty of low-hanging fruit to tackle for each of those. If I find there is a blocker to getting to acceptable typing latency and startup time, I'd consider making a switch (potentially to a react-native-on -desktop solution), but I'm optimistic that with WebAssembly, React 16, Chrome 61, along with optimizations on the Oni side, there's still plenty of opportunity to improve performance.
And I think the fat headroom for improvements is important to call out - when people talk about "Electron Bloat", they usually refer to one of 5 things:
1) Footprint (space on disk) 2) Memory usage 3) CPU usage (corresponding to battery life) 4) Responsiveness (esp typing latency) 5) Startup time
As you mentioned, across the board, there's a bunch of room for improvements - especially with tech like WebAssembly on the horizon! #1 and #2 are the hardest, because Electron will always have a fixed overhead - but when comparing to an IDE like Visual Studio, it's not over the top.
For my workflow, #4, #5, and #3 are most important, and Oni still has plenty of low-hanging fruit to tackle for each of those. If I find there is a blocker to getting to acceptable typing latency and startup time, I'd consider making a switch (potentially to a react-native-on -desktop solution), but I'm optimistic that with WebAssembly, React 16, Chrome 61, along with optimizations on the Oni side, there's still plenty of opportunity to improve performance.
For 1) and 2), I have an idea that it would probably be better if we can have an "Electron factory" running in the background and serve all these apps. This turns the OS task manager into tabs of a browser, and any optimization done by a browser to speed up tab opening and page loading, still applies here. :)
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.
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.
> 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.
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.
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).
Exactly my feelings. I was excited and then saw electron and immediately hit Ctrl-w
ActualVim has a similar goal and is a pretty strong PoC on top of Sublime Text (with less resource usage as a result)
'IDE powered by Neovim + React + Electron'
Electron, yes Electron
Electron, yes Electron
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++.
It's been done. https://github.com/google/xi-editor
There's some cool things to note about Xi which make me more excited about it:
* It's being written by Raph Levien, known for his work on Inconsolata, Ghostscript, and font-rs[1] among other things.
* The design goals include incredibly high performance, beauty, reliability and developer friendliness[2].
* It's very fast at handling large files, though the editor is still missing a lot of functionality.
[1]: https://github.com/google/font-rs
[2]: https://github.com/google/xi-editor#a-modern-editor-with-a-backend-written-in-rust
[3]: http://www.newrustacean.com/show_notes/interview/_2/part_1/index.htmlRather, it has been started. Xi currently is a very cool technology demo, but not a viable editor.
I've just recently switched over to it for my day to day work. Admittedly there are rough edges, but I think it's fair to call it viable for sufficiently small values of viable. I expect to do a major push later in the year to polish it to the point of being really viable.
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.
I use this plugin for previewing markdown https://github.com/suan/vim-instant-markdown
Even better: A rendered of graphic UIs.
The point about using electron is that you can use the browser to render the UI, and is filled with a lot of baggage. Imagine a UI rendered just for build UIs, not tied to JS or DOM or CSS, but able to work react-like.
The point about using electron is that you can use the browser to render the UI, and is filled with a lot of baggage. Imagine a UI rendered just for build UIs, not tied to JS or DOM or CSS, but able to work react-like.
You mean like react-native?
Yeah, but not with the full weight of node, js or (html)DOM.
For the UI something like TCL or Lua or just some DSL is better.
For the UI something like TCL or Lua or just some DSL is better.
That's still JS. React Native doesn't get rid of JS, it just exposes native platform APIs to JS.
JS isn't the problem though. V8 is pretty efficient and lightweight. The problem is that Electron pulls in all of the DOM stuff when there are lighter alternatives built into most operating systems.
> V8 is pretty efficient and lightweight
How much lightweight? Similar to Lua?
How much lightweight? Similar to Lua?
[deleted]
Sublime Text. Not Rust or C, but still much faster than Atom\Code. (Though I have to say Code team did a great job, it's nearly as fast as Sublime now. While Atom is still useless garbage)
Code is nearly as fast? Try opening a 10 mb file with syntax highlighting.
I'm curious, is this something you do in real life is it a synthetic benchmark? Either I open code files that are a few kB (needs syntax highlighting) or I open logs (which don't). Maybe your workflow is different from the rest of us but I can attest that for my needs, VS Code is rock solid.
I do. I have log files that I want to syntax highlight. In notepad++, this is a breeze.
notepad++ is not that great handling big files > 100MB, given that it is written in c++ and yes unfortunately sometimes you have such large log files.
Not sure if you've tried this recently, but I have. Code will open e.g. my 6.3MB (unminified, unzipped) vendor.js file for an app I work on, with full syntax highlighting, instantly. And scrolling is buttery smooth in it. :)
This was one of my problems with Atom. Code works just fine even with bigger files.
[deleted]
Text Adept [0]
Blazing fast and responsive even with 20MB+ files (in my experience), is extensible, and is cross platform.
Admittedly, not a IDE, and in C instead of C++. Extensions in Lua.
Not sure why it doesn't get more love.
[0] https://foicica.com/textadept/
Blazing fast and responsive even with 20MB+ files (in my experience), is extensible, and is cross platform.
Admittedly, not a IDE, and in C instead of C++. Extensions in Lua.
Not sure why it doesn't get more love.
[0] https://foicica.com/textadept/
What features do you want? There is Gnome Builder, KDevelop (also on windows), QtCreator, Visual Studio 2008, even vim itself. These are just some of the options.
Sublime Text
yeah I was like "SOUNDS COOL!" -> click -> React+Electron -> CLOSE
Here's another, very similar project, that is still actively maintained.
https://github.com/rhysd/NyaoVim
https://github.com/rhysd/NyaoVim
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.
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.
There is a config option to pick up your ~/.config/nvim/init.vim.
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.
Now this. I'm speechless.
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.
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.
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.
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.
> Performance - no compromises, VIM is fast, and ONI should be fast too. – the Readme
Yeah, that's why you use JS and Electron, right?
Yeah, that's why you use JS and Electron, right?
What do you mean? Javascript is incredibly fast.
"incredibly fast"
What
What
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.
High memory usage I'll give you, but calling it a slow language is very misguided.
My bad.. ..and that's why you use no compiled language, right?
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.
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.
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.
Already the vim mode in this is pretty nice since its powered by an actual vim.
I believe this was one of the stated goals of Neovim correct - that it would be easy to embed in other applications?
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.
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.
This racket msgpack implementation may be helpful:
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://gitlab.com/HiPhish/MsgPack.rkt
Though someone got started on elisp as well.
https://github.com/kleesc/msgpack.el/blob/master/msgpack.el
One of the advantages of evil is that you can program/extend it in elisp, and evil itself is emacs-aware.
I'm not sure to what extent the same would be true of neovim embedded in emacs.
I'm not sure to what extent the same would be true of neovim embedded in emacs.
The Vim extension now uses neovim for running all ex commands. I guess we'll see some progress into embedding neovim into another editor.
VSCodeVim is using ActualVim as a reference now, which afaik is the furthest along project for neovim embed (using Sublime Text). I think we wrote up a spec for proper embeds that's floating around somewhere.
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.
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!
Yes! It's looking really good so far, I hope you'll continue to update it!
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.
Mods, please append " and Electron" to the post title. Should save lots of people a click.
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.
VSCode is maybe slower and less configurable, but it is years ahead in terms of language support at least for tsx.
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.
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.
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
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...
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...
Why does it need to use Electron if it's using the neovim?
VimR is a decent graphical vim alternative that uses neovim under the covers (macOS only i think)
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?