Any reason why there's not more support for the Progressive Web Apps standard on desktop browsers [1]?<p>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).<p>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.<p>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.<p>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.<p>[1] <a href="https://developer.mozilla.org/en-US/Apps/Progressive" rel="nofollow">https://developer.mozilla.org/en-US/Apps/Progressive</a><p>Disclaimer: Please excuse me for recycling this old comment, because I do think the idea is still worth spreading.
Articles complaining about electron pop up at least once every month. One thing I always see missing from them is a better idea.<p>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.<p>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.
Disclosure: I am heavily invested in NW.JS(which is similar to electron) because my app is written in it.<p>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.<p>> 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.<p>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.<p>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?<p>Sure, it's slower and less resource-efficient, but is anyone making you use it?<p>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?<p>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.<p>Why can't it be fine for people like what works for them?
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)<p>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.<p>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.<p>> even the simplest elements like the native menu bar is not available.<p>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)<p>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.<p>While I'd certainly agree that a larger company that's pushing out a production product <i>shouldn't</i> 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."<p>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.<p>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.<p>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?<p>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.