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.

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.

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.

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

Maybe I should tell that to the guys that have paid my bills for the last 4 years.

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)

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!

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!

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.

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

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.

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.

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.

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