I think what Electron brings to the table and what most other contemporary technologies fail at, is cross-platform functionality with minimal effort.
In contrast to most other non-constructive comments about how Electron sucks, I think the focis should either be how to improve Electron (as mentioned by others) or on how to improve the cross-platform story for more native technologies.
What makes Electron so attractive is that it is so very close to write once, run everywhere. No other technology today comes close, which I think is evident based on the number of Electron apps out there. There are some native languages which have great cross-platform stories (e.g. Go), but few of them seem have a great fronted story. Today the problem is that all major OS platforms are pushing their own framework and language walled gardens, but I think most developers would like their apps to be cross platform if they could. This is an example of where the community has to do it themselves because the major OS developers seem to have no interest in cross-platform tools.
What would it take to achieve something like Electron but native? Why hasn't it been done yet?
"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 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.
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.
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.
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.
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.
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 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 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.
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.)
> 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.
> 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.
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!
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).
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.
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.
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.
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
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).
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++.
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.
Raph was also interviewed on the New Rustacean podcast[3] and talks a fair bit about Xi.
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'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.
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.
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.
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)
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.
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. :)
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
Neovim doesn't come with a graphical interface, which this is. (Though it does come with an RPC interface for controlling it, which is how this works.)
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?