> most modern apple native apps are the ones that crash the most while electron are stable as...

I'd hesitate to make this generalization. I need to use slack on a macbook for work and it crashes regularly. I tried out VS code and it also would crash on occasion. Worse than that, coworkers of mine have rolled bug-ridden electron apps that we're required to use. There are plenty of non-electron apps that are stable.

Not necessarily your main point, but this triggered me:

> coworkers of mine have rolled bug-ridden electron apps that we're required to use

This is quickly becoming one of those things I can't stand, especially when there are open source/free options out there. No, I don't want to use your homegrown application unless there really isn't a good option out there. And if that's the case, make it a good tool and release it OSS and try to get some traction behind it.

> No, I don't want to use your homegrown application unless there really isn't a good option out there.

Most 'home grown' corporate apps I've used are dependent on internal resources, processes and requirements. They'd be useless to anybody else, there are no alternatives anywhere at any money and in many cases you can't do big chunks of your job without them.

I'm on a mac and use slack an vscode. Neither has crashed on me. I'm wondering if there is something about your mac setup.

I don't like that slack consumes some many resources. I love vscode so I don't care.

He is likely holding it wrong.

I've seen VS Code crash on Windows more than Mac... also, it often leaves anything you had running in the integrated terminal running in the background when it does crash. I haven't seen that specific behavior on mac though.

Most of the issues I've had with VS Code were actually due to extensions and not VS Code itself. Like for example, we started getting issues with CPU's getting pegged to 100% and it seems it was a couple of linters that were running causing that.

What do these custom apps do and why aren't they webapps?

I'm curious. If you have 20 electron apps running, does that mean you would have 20 copies of the completely same thing wasting your disk space and RAM?

How would that work if all the application developers decided that native sucks and all should use Electron?

Yes, that's essentially what happens. And it's a huge waste if you have 20 Electron apps running. Each ships with its own copy of Chromium which is as large as an operating system.

I created a proof-of-concept called Electrino that uses the platform native libraries to cut down on app size: https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w...

Unfortunately I haven't had the time to work on Electrino due to family, etc. — I wish I did because the need is clearly there.

I've been thinking of something along those lines for years. I hope your project gets traction. I'd love to develop with web technologies exclusively, but what we've been doing with Electron is crazy. Imagine loading a whole new Win32 or Carbon/Cocoa for every app you open.

I can understand the inconsistencies and lack of feature support that could emerge from using a different browser engine for each OS (Webkit/Edge), but there should at least be away for Electron apps to share Chromium/Node runtimes between them.

Isn't this basically what PWAs will hopefully solve?

Rather than Spotify, Slack, Discord, ... all coming with their own Electron bundle they can be packaged up as a PWA and use the browser as the runtime environment along with all the nice offline stuff, safe OS integration for notifications, sandboxed file system access, ability to still do some work in S0i3 (aka Modern Standy on Windows), etc.

Or am I totally wrong about this? I am not a web developer so I could be :)

Bonus question: how would this work for things like Atom and VS Code that are electron based. Could they become a PWA?

All good questions and some things will probably be well addressed by PWA or whatever we decide to call JavaScript rich webpages by then.

But some UI issues, like the lack of a proper menu, browser's chrome and address bar will still be a turn off. Besides, having unrestriced access to the user's drive is not something a web page should be able to do and is a must for something like a text editor.

There is BrowserFS https://github.com/jvilk/BrowserFS

There's no reason a text editor, or most applications really, need unrestricted access to a user's disk. They have to prompt the user with a file open dialog anyway, so you may as well let the OS handle that and pass an fd/handle across the boundary for you.

What if you are using a smart IDE like editor that, for instance, minimizes and concatenates your css and js files?

It’s going to want access to all files in that directory, not only the ones you are editing.

tbh that doesn't sound like a huge problem to solve. Setup some working folders that the PWA has R/W access to and leave it at that.

Browser chrome and address bar are not an issue as I believe a PWA can run in a generic application Windows with it's own icon, etc. Similar to if you have used a Chrome Web App in the past? Unless you go looking for it you wouldn't know it was running within a Chrome process.

Not sure how menus are handled. A standard menu API would seem to make the most sense to me?

What is "PWA"?

Progressive Web Apps, but I honestly can't explain exactly what they are.

It's the combination of various technologies helping make websites which pretend (poorly) they are applications.

Hey, I saw the post that got the ball rolling on Electrino and I've been meaning to reach out to you. Do you have any tips on where to start on porting Electrino to Linux?

Electron-like "web" apps (that follow W3C standards) seem to be the future, and I'd love to help out however I can.

Great! I use desktop Linux regularly and I have some ideas where the Linux port could start off. Would you drop me an email at [email protected] and let’s talk?

Why wouldn’t google just ship a “libchrome” shared library so that they could share it?

They do, it's called Google Chrome.

Because google is more inclined to break their own APIs without concern of the integrations of others.

Adobe AIR was an effort to create a common runtime for similar things... wouldn't mind seeing a few OS vendors coming together to support something similar, but on the flip side, I don't want to be stuck with Node 4.0's API in 2024.

20 electron apps would be 20 copies of mostly the same browser

You also have 20 security nightmare apps running

> im really fed up with this argument. most "native" apps use big chunks of the platform "frameworks" [...]

Yeah, and that's a good thing. Furthermore, there are toolkits that don't, and they are still more efficient than Electron.

It's better (and more efficient) to have a developer write (or waste, if you consider doing their job "wasting time") two interfaces than to waste the computer resources of a million people.

Electron is just outsourcing cross platform development to the Chromium project.

Unfortunately waste of users' computer resources is an externality and developers are more expensive than ever. Revealed preferences show that customers would rather buy more hardware resources than pay higher prices for efficient software (within reasonable limits).

I would be careful talking about revealed preferences here - individual customers have close to zero choice in the matter. They select from what's available on the market, not from the space of all possible software.

If the efficient market theory is to be believed, then as soon as a competitor shows up with the user's preferred choice, they will gain the market share.

The fact that no such competitor exists is evidence that the user's preferences aren't what you stated, but is in fact consistent with reality, namely they prefer free and bloated.

The mistake here is believing in efficient market theory.

It's not so easy for a competitor to show up, because they have to work against heavy first-mover advantage and network effects in software. Those who do a crap job get first to the market and set the trend (and the expectations). Moreover, there's a heavy component of tragedy of the commons here, with commons being users' computing resources - the software is often designed with implicit belief that it's the only thing running on user's machine. It's enough to make a sale, and you don't get a reward for making it so that your users can run many other stuff simultaneously with your application.

Generally I agree with you but for Electron we're talking about own-goals the developers inflict on themselves. No one outside of the HNosphere uses Electron apps.

Plenty of people outside of HN use Slack, Discord, Atom, VS Code, Skype and Twitch.

Right now I have Discord, VS2017, a Postgres IDE and a bunch of Chrome tabs open. Task manager reports for memory usage (descending order): Discord: 1168,4MB, VS2017: 463MB, Chrome tabs: about 300MB each, PostgresTool: 152MB and the rest below 100MB. If I dont include all the chrome tabs, Discord uses more memory than all the other apps together, and some of them are "big" apps.

So my 32GB RAM, high specs system, is able to run only up to ~ 30 instances of Discord, not counting even the OS.

Wtf. It feels like malware.

That's why I have a simple rule:

"No JavaScript on the desktop"

And suddenly 8GBs of ram is at least 4x too much(Linux) even when I'm using "bloated" Java apps...

https://suckless.org/sucks/web/:

  Millions of jobs are based on outputting HTML in an inefficient way.

Then perhaps OS vendor should start thinking about unifying their UI SDK using web engines, because having to support the finicky toolkit of every OS is a waste of engineering time.

That was Boot2Gecko aka FirefoxOS. I would not mind having that on a phone.

> Electron is just outsourcing cross platform development to the Chromium project.

... and ultimately to the consumer, who pays for higher spec'd hardware and more electricity.

> most "native" apps use big chunks of the platform "frameworks" and are not platform independent, which was introduced by os companies and politics in the first place

That's the point. Why download another framework when you have one on your computer already that's tailored to your platform?

All of the mess in apps belong to developers and it has very little or nothing to do with the underlying framework.