Any reason why there's not more support for the Progressive Web Apps standard on desktop browsers [1]?
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.
I'm 100% in on the PWA on desktop idea. It's already implemented in mobile browsers, how hard should it be to implement it on desktop?
As a bonus you'd get always up to date apps and browser runtime, saving your bandwidth, because there will be no need to re-download electron runtimes.
Articles complaining about electron pop up at least once every month. One thing I always see missing from them is a better idea.
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.
As a full time web developer, I liked the idea of electron. Even if I dislike electron apps that I need to use at work (like slack memory glutton).
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.
Depending on your needs, there are quite a few of them.
For smaller or non-commercial projects, you can use the free version of Delphi. Creating a native desktop app is superfast. The downside is that if you need multiplatform support you need to pay.
If you care about Windows, you can just use Visual Studio and one of the languages included.
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.
Disclosure: I am heavily invested in NW.JS(which is similar to electron) because my app is written in it.
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.
As someone who doesn't particularly like Electron, I have an honest question: Why all the hate?
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?
I have a Surface 3. It has enough memory for my web browser, but not much more. Atom is out of the question, Spotify grinds it to a halt, slack is a horrible experience.
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.
> 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.
Perhaps you're being hyperbolic, but can you give an example of an application that runs more or less the same functionality and performance on a 30 MHz processor with 12MB RAM (a high end computer from the early 1990s) as a 3GHz processor with 12GB of RAM (a high end computer from 2017)?
I'm guessing you're not very old. Interleaf on an original MC68000 Sun workstation. The Symbolics Genera IDE. Pretty much every app on an Amiga or Mac II circa 1990. Most of these apps were more responsive and more capable than Electron with single cores and 1/1000 the resources. Making clickable animated widgets on a windowed screen that tightly integrate with the OS doesn't (or shouldn't) take much software. But we seem to have forgotten that.
I understand the hate. It solves the problem like hammering a nail with a wrecking ball. But having said that, I'm actually using it right now. Mostly because I already know when development and I don't really have the time to learn GUI libraries, also I can get up and running with a workable UI in less than a day with electron. However I just discovered sciter and might use it for my next project.
One issue is that Electron apps don’t get browser security patches until Electron updates Chromium, the developer updates Electron, and the user updates the app.
While that's true, electron apps very rarely provide unrestricted web browsing of untrusted content. They're usually locked to a single domain, or load their entire interface from local files.
This doesn't make it safe -- consider a lower level library inside Chromium can be exploited when processing input data. Your chat app can be exploited by receiving a crafted image. This actually happened in image processing library and network library in Chromium.
Sure, but the same can happen to whatever libraries you use on your native app. If anything Chromium is more likely to be patched, since there's a large entity interested in keeping it secure enough for accessing untrusted content.
You can just use an alternative. If the company you work for is mandating that you use specific tools, that's a different issue, orthogonal to electron.
Software development is primarily an engineering discipline, so cost and time to ship must be weighted along with performance. (a classic example of a trade-off) There's no point in making things more performant than required. (Except perhaps from an enthusiast/hobbist/academic/curiosity perspective)
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.
The accessibility that electron has makes it invaluable for me personally. I use it to create tools internally; tools I simply wouldn't otherwise have the time nor capability to create. In this respect, Electron is extremely helpful, not harmful.
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.
> "Well, it works fine on my machine, and I only have 32 gigabytes of ram."
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.
> You are not your end-users, and you if you are a developer most likely do not run average hardware.
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.
Electron apps could be resource hogs, but VSCode is my favorite editor by far! I don't care if it'll load 1 second later. Same goes for others like Slack, Discord, Spotify. I want them to look the same everywhere I use them. I just don't care if I'll wait a bit longer for the window to show up.
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.