This frustrates me a lot too. Whenever I encounter non-crossplatform Electron apps, I extract the mac or windows app.asar files and so far, all of them have ran fine on Ubuntu. That means it's just a matter of not taking the effort to package the app for multiple platforms. I get that packaging is not the most exciting part of application building, but it's not rocket science either.

If anyone has an Electron app and wants/needs help with cross-platform packaging, feel free to contact me.

It's not even that exciting with electron-builder. Especially not for Linux, as there's zero things you need to configure, unlike Win/OSX.

Perhaps you've written a guide you might like to post on hackernews?

Hi, have a look here later https://github.com/720kb/ndm#faq

"As soon as we are sure that the project is stable, it will be delivered to the other OSs." :)

Why do you disregard one of it's main benefits? MacOS development is notoriously tricky, so to enable it for the largest class of developers today makes a lot of sense.

The other big advantage would be speed of iteration - particularly in a startup environment, being able to iterate on designs, layouts and functionality fast is a huge plus of working in JavaScript / HTML over native constructs.

Agree thanks :)

Let's flip this around, what are the benefits of writing a native app when there is Electron? It's democratizing cross-platform Dev tools in one of the most standard rich environments, the browser.

IMO, the question should always be, why native?

> Let's flip this around, what are the benefits of writing a native app when there is Electron?

- Speed

- Native UI

- Native OS hooks

> Speed I'll give you that, but performance is not the most important factor for most users of most applications.

> Native UI Coming from someone who has done web development and iOS development, who tried native development for osx then switched to electron with react and redux, I have found it faster and easier to completely recreate the look and feel of the native osx views while adding custom functionality than to add custom functionality to natively. Appkit sucks and many of the improvements they've made over the years are only available in recent osx versions.

The development experience is much better using VSCode than Xcode too. That's insane. A 2-3 year old web based text editor should not be a better, faster, and more stable development environment than the 8th version of the of the IDE from the most valuable company on the planet.

IMO those are specific choices for specific types of applications, when most people just need a simple front end for their app.

What about the energy performance hit that electron apps introduce?

I haven't noticed it, and use Atom (Electron based) on a Laptop often. It's a MacBookPro, so already one of the better in terms of battery consumption, but I use it disconnected from Power for upwards of 5-6 hours at a time with no issues.

The number one reason why I personally prefer native apps (at least os macOS) is the fact that they consume way less battery than Electron-based ones.

If NeXT was written after the browser (rather than being used to write the first browser), I believe the OS windowing toolkit would have been HTML and CSS based, rather than postscript based.

If you consider macOS' use of postscript rendering as roughly equivalent to that of what a browser does with rendering the DOM, then I think we start to see what Electron represents.

I personally haven't developed with Electron, but I'm hoping that there are ways to hook to native code where needed, just like Apple does from Postscript to Swift/ObjC/C.

Electron is really cool, though I think it's slow and big.

Also sometimes laggy, when you operate with huge volume of data.

Take as an example editors. You can't compare the speed / size of Sublime vs Atom. Both are cross-platform. First is written with C++ ( AFAIK ).

I mean, web tech is more straightforward to work with / easier to find information on than desktop app platforms in general.

Yes, is a different approach and has pro and cons.