For me, I'd just love it if progressive web apps would have a desktop offline install mode that allowed them to deliver notifications, a desktop icon, and a separate window.

I was expecting this to happen after chrome discontinued their "chrome apps", that the underlying tech would come back with progressive web apps, but I haven't seen anything in that space.

I think it would solve the problems with Electron apps (wouldn't have to rebundle the runtime for a massive binary size and massive memory use).

If anyone knows if anything is happening in this space (progressive web app installation for desktop) please let me know.

I am looking forward to more PWA and I agree this would replace most use cases for Electron, but not all.

If it's just a web app (network, localStorage etc) then it would be fine. But if you need to read/write to the user's filesystem or need to include other executables then we can't run that in our browser. We don't want a webbrowser to have any possible path to screwing with your filesystem or running executables.

There is a flag for it. I was surprised that my website 'installed' on my Linux PC, created a '.desktop' file and launched in a separate window. It works now, only bug I encountered is asking 'add do desktop' while I already launched it from desktop

Really? Awesome! What is the flag? I couldn't find it when googling about for information a few weeks ago.

EDIT: Found this: https://mobile.twitter.com/nolanlawson/status/71266809721643...

Look at it from a product owner's perspective. I want 100% of users to have the same experience. Electron bundling a web runtime that gives the same experience on each platform is absolutely key to giving them the same experience. There may also be security issues to consider.

Look at it from the computer owner's perspective. I don't want your experience if it comes with 100+ MB of redundant code.

Isn't that size arbitrary? Downloading and storing a 100mb program takes the same (or less) fraction of your available resources today as downloading and storing a 1mb program in 1995.

Are you short on disk space? Download is too slow? Is this a real problem?

Download size is relatively harmless; size on disk is an annoyance and a real concern (a lot of laptop users have an SSD in the 128-256 GB range); but memory footprint is the real killer for me. I don't want every little widget to consume hundreds of megs of memory.

In 1995 my computer had 8 or 16 MB memory... Having a 1 MB app running in the background would have been huge. I certainly don't want to go back to that era.

Memory footprint is my big issue with this too. Related, I've noticed chat for various projects slowly migrating from IRC to Slack and have the same issue there. What could have been another irssi window taking up an insignificant amount of memory is now a 150Mb Chrome tab.

To make matters worse, memory growth has stagnated. A Macbook Pro today, to give an example has the same maximum RAM (16Gb) it did in 2010. That's zero memory growth in 7 years for a popular developer machine.

Wouldn't regular Chrome have the same issue? Each tab is a full instance... your argument is against Chrome and web apps, not Electron.

No, it's different.

Each Chrome tab is a process, but they share the same dynamic libraries in memory. Each Electron app is both a process and a separate copy of the dynamic libraries.

If you run half a dozen Electron apps, those redundant libraries will be taking up roughly a gigabyte already.

Chrome splits itself in various processes and usually each tab has a process. But each process is not a full Chrome instance. There's a huge difference.

Would people give shit if Spotify was 100 Mb?

if Spotify were the only app using Electron, it wouldn't matter.

But when every utility and menubar widget has its own copy of Electron, the footprint balloons quickly. And people are actually doing those kinds of apps in Electron already!

Which product owner? Totally agree with you, but the reason why it's delivered this way right now is a technical implementation detail. Electron could focus on delivering an API that abstracts away differences between runtime engines (as most web frameworks do). I'm sure bundling chrome in is a boon to simplicity inside electron, so maybe the distinction matters within electron, but i'm not sure that distinction should matter for downstream projects...

Not wanting your users to have an "experience" that matches their OS IMHO is bad design.

That is not a valid thing to want. The experience is supposed to be different on each OS.

That web runtime doesn't ensure that people have the same experience. You're still relying on the abstractions of that runtime. Plus that there haven't been any changes to it.

Can you elaborate? Are you saying that Electron apps have portability issues?

Well, why wait. I made a repo for "Electrino":

https://github.com/pojala/electrino

Sorry, it's totally empty! But I'm hoping to get around to making a Cocoa+WebKit proof-of-concept this week. I guess the starting point would be to implement just enough APIs to be able to run the main.js example from this Electron tutorial:

https://github.com/electron/electron/blob/master/docs/tutori...

Another direction might be to extend Cordova to support macOS and Linux. Cordova already supports building UWP for Windows Desktop/Xbox/HoloLens using the native HTML+JS stack. Seems to me like a lot of existing Cordova plugins just need subtle nudges to support macOS in addition to iOS. Then you just need a good Linux solution and you cover all the desktop environments.

Then narrow the few missing desktop-focused APIs that Electron has but Cordova doesn't have good plugins for. (It would also be nice to support more Node-like background processes in Cordova and more Node-native libraries, but you would need to find a good balance that plays well with mobile.)

There's also React Native, which can work on macOS (https://github.com/ptmt/react-native-macos). I'm not sure about other operating systems, though.

Microsoft has put out an implementation for Windows, too: https://github.com/Microsoft/react-native-windows

Update on Electrino: implemented minimal APIs to load Electron's "Hello World" example. Code is in the repo.

Only having to target a single browser does make life easier for application developers. It's like programming for the web, but without the hassle of cross-browser compatibility.

It just astonishes me how big the slack install is. It is like installing the latest video drivers from Nvidia or AMD.

What's the purpose of the Slack desktop app? What does it do that the web app doesn't?

Primarily, it sits as its own entry in your task switcher, and can show the number of pending alerts you have. It also uses OS native notifications, though I know that's increasingly possible through the web too.

When I did use Slack to communicate with remote coworkers. I just kept a tab open - with notifications turned on. Most of the time I was working with three monitors anyway.

Now that I only use Slack to communicate with former coworkers I just keep it on my phone.

Isn't this more of a philosophical problem?

Static binding vs dynamic binding?

Bundling everything up so no outside deps are needed vs using everything that is on the system to save space?

Yes, and I wish developers could make that choice more easily.

The Electron approach is fine for genuinely large applications. But I've seen many Electron-based Mac desktop apps where the UI has a handful of elements. The equivalent Cocoa app would be maybe 100 kB.

I understand that people won't learn Cocoa just for tiny UIs, so it would be really nice if there were a mostly Electron-compatible solution that would use the system web runtime which is already there (and probably already loaded in active memory).

It's funny somehow.

They built a framework for, as you say, "genuinely large applications" but it seems to be so easy to use that it's used especially for small ones.

And if you are building a large app you'd benefit from a statically typed language with better native data type support than JS.

OpenFin claims to have remediated the memory issues of electron somewhat.

https://openfin.co/2016/11/04/openfin-slashes-electron-memor...

The con is not all browsers support the same features. Sure, we've come along since IE6 and Mozilla but if I'm creating a web-based desktop app, I want to deploy with 100% certainty that the CSS/JS I used works exactly the same when I was developing it.

Update: I decided to build a proof of concept for Electrino. It can run a "Hello world" now.

Here's the Show HN:

https://news.ycombinator.com/item?id=14260755

Or even Chrome itself.