Hacker News Reader

Comment by lossolo | Hacker News Reader

> What are the remaining APIs that people need in Electron that are not available in the web browser?

I don't think APIs like full access to filesystem will be available in browser because any malware could do anything it would like with your OS/files.

So in a lot of cases you can't really replace Electron with just normal webapp in browser.

View on HN

Or maybe some form of web archive format signed with a certificate? "Do you want to install Slack? It will have access to X, Y, Z"...

We already download programs off the internet and let them run with local privileges all the time, it should be possible to safely and securely extend the capability to programs delivered as html+css+js.

Also I don't see why Electron+node isn't installed system-wide like Java or .NET. Yes, I know it's because node is a server technology whose devs aren't interested in being Java, while the people shipping electron apps are just interested in the lowest friction to deploying native apps to customers, but it still seems like the kind of thing someone would have done already if only just to show off.

Microsoft had HTML apps as a standard feature of windows in the 90s iirc

https://en.m.wikipedia.org/wiki/HTML_Application

And they are first class citizen on UWP (aka WinRT), long before Electron was a thing.

https://msdn.microsoft.com/en-us/magazine/jj891058.aspx

To be fair, .NET has the capability to release applications with all the pieces required in a single exe. At least core does, anyways. That's a pretty big selling point for golang, as well, in my mind. Electron is the same thing in my mind, just on a much larger scale. Maybe it's too large to be sustainable in the long term, but there are definite benefits to having a single, self contained package.

They're still not there with the Golang-style single exe for .NET Core. The default behaviour of the dotnet build tool seems to be to build a .dll file (!)

Have you looked into "Self-contained deployments"?

https://docs.microsoft.com/en-us/dotnet/core/deploying/

On the Windows side, .NET Native does static linking.

No, but you can use an extension/native helper and talk to it from the web app using network calls.

Might as well just use electron at that point since it's easier on the developer side.

But even worse for the user than a web browser already is.

Can we, instead of combining the worst of native apps, web apps and containerizaton, maybe work towards removing SOME of the terrible aspects for users? If developer comfort is the highest priority you might as well skip making the interface look nice/useable.

Electron really is an extension of Chrome and it'd be damn nice if it could be shipped as one.

Uh, aren't users the most important factor here, not developers?

Sure, such that in my experience users prefer dedicated apps most of the time.

For example, Postman (browser-based HTTP client) has some of the worst UX because it's a Chrome app and not stand-alone. Can't event alt-tab to it. I have to alt-tab to Chrome and then find the Postman window.

Users also prefer to be able to use more than one program at a time on their computer, so please, if you have to use Electron, keep an eye on performance characteristics of your application.

I'm not a heavy user of Postman so I can't say if the UX was improved by it, but Postman actually moved to Electron last year: http://blog.getpostman.com/2017/03/14/going-native/

Only to a certain degree.

As market shows it's not about what you can do but what is the easiest and fastest way to make a product.

I've created Electron application also, not because it's the best solution on the market but because it was fast and easy way to get my app to the users.

If I had time and resources I would probably just use Qt or created native app for each platform.

Can you name even a single app that _actually does this_

Can't there be separate contained instances?

Reply on news.ycombinator.com