I obviously prefer to use native apps as well, but your comment sounds like some sort of bizarre moral judgement, not a rational programming decision.

In a way, it is a moral issue.

By choosing to go the Electron way, you're imposing a huge computational penalty on your users, just to make your life easier. Now multiply the overhead by the number of users, and that's how much electricity your decision just cost globally. This also manifests in frustration, like due to decreased battery life on laptops. And with enough popular software written this way, this pushes users to replace their perfectly good computers earlier than necessary.

(The lats point applies to web bloat even more; I'm really annoyed when a non-tech person asks me for help, because their computer "works slow, it must have viruses", only for me to discover that the computer is perfectly fine, it's just their favorite pages went through another rewrite and are now each 5x more bloated than they used to be.)

You are probably right, I'm being highly subjective. I loathe the entirety of Electron & consorts with real passion, retrograde, unfashionable bittweaker that I am.

Especially when the OS vendors are at fault by each pushing their own API for the same thing to wall their gardens.

We can only defeat that by having another awkward "OS" in a VM which browser/electron is.

I don’t like walled gardens any more than the next guy, but it’s easy to push this argument into absurd territory. Are OS vendors required to offer identical APIs, to the point where it’s immoral for them to have differentiated functionality and useful features? What is even the point of having different operating systems then?

Common APIs between operating systems also introduce the common denominator problem: if OS vendor A wants to add some cool new API for third party devs to use, they have to wait until other OS vendors also implement that API, otherwise they risk other OS vendors never implementing it and devs never using the API.

Or, as jacoblambda wrote several comments above, just use Qt.

The most obvious counter-argument: one shared codebase vs. your five.

Native is awesome when you have the money.

Not exactly. I am building HTML-NOTEPAD (https://html-notepad.com) from the same sources ( https://github.com/c-smile/sciter-sdk/tree/master/notepad ) for all desktop platforms.

It uses sciter (https://sciter.com) which is sort of micro-electron if you wish. Distribution of the app is 2mb rather than 200mb.

People have been writing shared codebase apps for decades even before the Javascript craze.

What do you think the cross-platform browsers you're packaging in Elecron are written in?!

> What do you think the cross-platform browsers you're packaging in Elecron are written in?!

The cross-platform browsers are written in a whole lot of platform-specific code.

False dichotomy. There are plenty of ways to share code across these platforms, without writing everything in JavaScript.

Meh, I write cross platform applications, single code base, and compile to native executables on Windows, Linux, and Mac with no problem and no extra Chromium bloat.

FreePascal + Lazarus.

I've done delphi in the past but I haven't heard about it for a while. How big is the community nowadays? What about libs? Package manager? Dependency-hell? Unit-testing frameworks and other toolings? How easy is it to stop the whole application and inspect everything, evaluate some code in parent stack and see if the issue was resolved so that you know exactly what to do?

It's not only about GUI designer and fast cross-platform compiler.

Online package manager can search, download, and install packages.

I have libs/packages for everything I need, dunno about your needs.

Not sure about the community size but it's plenty big and plenty helpful, lots of cool new stuff going on.

Plenty of debuggers available and you can pause things and inspect stuff.

Lazarus has seen loads of updates the last few years, it's worth taking the time to set it up to fit your needs and learn the shortcuts.

How do I run that on web, the most important platform today? I'm also not aware of any comparable community like Node.js has.

And I say that as someone who was writing Pascal professionally ~5 years ago.

We're not talking about web applications, we're talking about Electron.

But sure, if you want to do Pascal on the web there are things like Smart Pascal.

We're talking about ways to do multiplatform applications, which includes the web. You suggested Pascal but that doesn't run on the web without changing the code. Enclosing the application in Electron shell does not mean it's the only way it's going to be ran, actually most of the time you do it because you already have a web application and a server.

You can't run an Electron app on the web without changing code either, seeing as it's a browser AND a webserver combo.

You also don't take a webapp and separate server and just drop the two into a folder and run it as an Electron app without changing code

Not true. You can code the app in a way that allows you to share code completely between web, server and Electron app; there will just be a little boilerplate in the Electron app around it.

Much less difficult if you follow basic software engineering practice when writing your software - split out platform-dependent parts and abstract them away, write remaining 90%+ of your codebase without worrying about the platform.

The day OS vendors come together and standardize their API's, much like browser vendors do, I will build apps with native code.

Well Qt is pretty much there for desktop. Almost everything can be done in a relatively straight forward, platform independent way as long as you aren't doing mobile.

>as long as you aren't doing mobile.

That to me is the biggest issue. There's "cross platform" and there's "cross platform".

QT gets you the major desktop platforms, but not a ton more.

The web gets you desktops, mobile phones, tablets, game consoles, TVs, car infotainment systems, even my fucking watch!

Obviously you aren't going to handle all of those without some custom code for a few platforms, but when the web is a target platform for a project at all, it's often worlds easier to just spend the time on improving the mostly single codebase rather than try to do multiple codebases. And I genuinely believe that outside of larger companies, having the whole company dedicated and focused on improving one codebase is going to end up with a better user experience than splitting those same resources up over several codebases.

If your app is desktop-oriented only, then Qt is such a fantastic system to work with! But it's increasingly rare that software targets desktop only.

My problem that I find is that mobile, consoles, TVs, car entertainment systems, watches, and so on all need fairly distinctly different UIs from desktop and if you have to redesign the entire UI for them anyway, then why not do it in a native system that handles them well. Odds are most of the heavy lifting will either be fairly trivial or done in a separate back-end be it on a server or locally. At that point it doesn't really matter what you write the front end in as long as the back-end has a decent API.

Also quick edit: A number of car dash UIs do actually run on Qt and Qt does support mobile but Qt does its own compositing instead of the OS.

Can you give an example of a good Qt application? The only one I’ve used recently is VirtualBox, which is terrible, but I don’t know if that’s Qt’s fault or not.

The Battlenet launcher from Blizzard is a decent app that suprised the hell out of me when I found out it was Qt. Some others are Maya, EAGLE, Krita, Mathematica, VLC, and Dolphin emulator.

There are multiple libraries that give you just that with significantly lower footprint than a full browser engine (which is just a horribly inefficient blob of bloat you're trying to use as a cross-platform shim).

uhm, browser vendors literally got together and standardized APIs. That doesn't mean there's no bugs or unspecced territory in the current implementations. Obviously these need to be solved. Through more standardization.

> someone has been doing something entirely wrong.

Agreed. Seems like there is no alternative, though; what you said in your first paragraph definitely is not a comparable alternative except if you're handing out money my company could use to do what you suggest.