Sure, it's slower and less resource-efficient, but is anyone making you use it?
Yes, it makes it easier to "just use your web developers" instead of hiring native app devs, but how many of those apps would even exist if the only path was to develop a native app?
Electron is too slow for me, so I just stick to e.g. Emacs and Sublime text. Other people get along just fine with Electron, and love VS Code.
Why can't it be fine for people like what works for them?
But you know what works great? Emacs, a shell, Python, video players, bittorrent, ffmpeg. I. e. native apps.
Well, that sucks for me, right? I could just hop on my 64 GB, 32-thread desktop PC right? As a matter of fact, I could, because I am an entitled white western dude. But the rest of the world can't. I wonder how the Atom vs Emacs debate plays out in China or India or Africa.
So there will be companies writing less demanding software for less developed countries that will reap all the market, audience and benefits, right?
This is similar to the diversity argument: "hiring a diverse team is beneficial! only staying diverse you can have innovation" is similar to "billions of people are stuck with slow hardware and ancient OSes - these are the markets of the future".
Guys, why don't you all form a diverse team, go capture the market of the future and become billionaries in the process while we keep on writing Electron apps? Sucks to be us, right?
Because it's simply offensive to me as a computer scientist and software engineer to use most of the resources of a 3GHz processor and 12GB of RAM doing something that really can be easily done with a processor 1000x slower with 1000x less RAM. I'm willing to accept a certain amount of overhead for modern user interfaces and cross-platform capability, but three orders of magnitude wastage is ridiculous. It literally offends me.
Yes. Is impossed on the users by the developers using it.
No more than chocolate is "imposed" on people consuming it by the chocolate manufacturers.
The reason electron is prevalent in businesses nowadays is because it's easy to develop and deliver to customers. Apparently this comes with the price of performance loss.
Please, the next time you feel the need to use your time to write an article about how electron is "cancer", try spending a little bit of time brainstorming a better solution that still fits the bill.
It gave me the impression that I can build desktop app faster by reusing my skills. When it was time to build some side project, I did them in electron.
Recently I decided to learn c#, for unity initially, but I decided to try xamarin. This change all my perceptions. Not only building the core was way more enjoyable that with js/babel/nameit. Prototyping the native interface was faster, and developing the final UI was also more productive. Not to mention the final product looked better.
Comparing developer productivity is hard, but based on my own experience, I would say that it would have taken twice the time on electron the finish the same app in the same time. Compare to my other similar electron project, it load faster, don’t use cpu cycle on idle and consume ¼ of memory.
Maybe there is better idea than xamarin, but at least is seems like a better idea than electron. Now I see more electron as a fast way to have a webapp on the desktop or a fad based excuse to not learn something new.
On the other hand, calling a "cancer" is quite absurd.
If, however, you want a free tool to rapidly create multiplatform apps, I think the only real contender is Lazarus. It has some rough edges at places, but it works quite well, you can construct medium-complexity apps quite easily, and it's really fast.
It seems to me that many Electron apps these days (most chat apps: Slack, WhatsApp, Discord, etc) are super-thin wrappers around a web app that don't actually need the full desktop access offered by Electron (things like local filesystem access, multi-process execution, multi-window management, arbitrary node APIs, etc).
They just need a way for users to "install" the app so that it 1) has a separate shortcut and appears in a separate window from the browser, 2) can send notifications through the native notifications stack, and use a fallback on systems where one isn't available, 3) is available for use offline.
The Progressive Web Apps spec has answers to all of these problems, and it would vastly improve the resource usage model compared to Electron because each PWA would share the same browser runtime as the user's browser of choice, which is more likely than not running 24/7 anyways.
I know PWA was designed with mobile apps in mind originally, but it'd be a shame to limit it to that use case, as there is clearly a lot of demand for building desktop apps with web technologies, and PWA sounds like an excellent alternative to the current status quo that's dominated by Electron.
[1] https://developer.mozilla.org/en-US/Apps/Progressive
Disclaimer: Please excuse me for recycling this old comment, because I do think the idea is still worth spreading.
I think this article complains about a problem, but that problem is not necessarily caused by electron, or electron as a whole. Hear me out. The memory leaks could be bad code in the application itself. If the memory leaks are from electron, the problem still isn't electron as a whole, it's the leaks themselves and should be fixed in the electron code.
> Bottom line; as an end user I really could not care less about how easy it was for you to make the application, if it is not working properly it is not working properly, being slow on today’s super fast hardware is a bug.
Sure you do, by proxy. If it was easier to write, there will be more and better features, which you definitely care about. Therefore, the easier to write, the faster to develop, the more polish and the more value there is. Again, if the problem is performance, then fix the problem, don't curse the whole system.
I find many pro's making NW.JS well worth it. I can fix the performance problems as they arise, and just because developers of certain electron apps don't address performance, does not mean electron as a whole is bad.
If we can ship apps on Windows, Mac and Linux with a near native experience, a fraction of the cost and benefiting from readily available professionals with web skills, that's fantastic.
Don't get me wrong, there are several classes of tasks where performance is a requirement. For these, Electron is indeed not a great choice. However, it's usually possible to combine it with a more suitable technology to get the desired results. For instance: VSCode uses ripgrep, a command line tool written in Rust to provide the fastest possible search experience.
> even the simplest elements like the native menu bar is not available.
Not entirely sure what you mean by that, VSCode has a completely normal menu bar on both Windows and Mac, and context menus are also native. (At least on OS X; on Windows it's hard to know what "native" even means for context menus since UWP apps and Win32 apps have completely different styles for them)
By the way, if there's a market for more efficient competitors to electron apps, these will flourish and electron apps will "lose", but that doesn't seem to be the trend.
While I'd certainly agree that a larger company that's pushing out a production product shouldn't use Electron, calling it harmful overall is like calling 3d printing harmful when injection molds / CNC milled products have a better finish. It's about using the right tool for the right job. Just because it's slow doesn't mean there isn't value in how quickly you can create things in it.
Tangentially, this problem is not limited to Electron. Developers should regularly test (and why not also build) their software on an old laptop with 2GiB of RAM.
I don't get why I have to bump the maximum heap size of Gradle daemons to 2 or 3 GiB just so they don't barf under their own GC vomit. Building an in-memory representation of your project's modules and dependencies (even hundreds thereof) should not take more than a few MiB if done correctly.
Then your end users won't buy your product and you will be forced to write a native application to not go out of business. But if your users can run it and your product is successful (ie Slack) why do you need to spend more resources to make it native?
This is like the "supporting IE matters" thing. It does matter if your target uses IE. If only a negligible slice of your target uses IE, it doesn't matter.
