When someone makes a platform as easy to use as Electron that makes tiny executables with zero friction and lets me easily style and debug a live running app I'll switch. Maybe that already exists?

My previous experience with native dev is that every platform requires 1000s of lines of platform specific setup and then special code all over the place and further I need deep familiarity with all the different platforms' APIs

On Electron, if I start on Mac (you can start anywhere), it's

    npm init -y
    npm install --save-dev electron electron-builder
    git add .
    git commit -m "initial commit"
    ./node_modules/.bin/electron-builder

Then I ssh to a linux box, clone the repo and

    npm i
    ./node_modules/.bin/electron-builder

Then I ssh to a windows box, clone the repo and do exactly the same thing.

I just created all 3 apps. On each platform the file is setting in the 'dist' folder as a .dmg in Mac, an .exe on Windows, an .AppImage on linux

No other installs needed (just node), no installing 57 standard or custom libraries and runtimes. no sudo apt install for dependencies. No setting environment variables telling various compilers where they can find stuff, don't generally even have to run my code on the other platforms even, an app pops out and I'm done. And, if I've written tests they'll generally work similarly, "npm test", zero friction, zero extra things to worry about.

If someone want's to beat Electron those are the features they need to provide.

> with zero friction and lets me easily

You made a whole case for things that make your life easier. Any remnants of interest for what would be in the user's interest? Let's not kid ourselves, you saving some effort is not for the user more than say charging double for your software is.

But perhaps that should be left in the hands of software engineers.

As a counterpoint I have come across lots of software that is only developed for one platform and unfortunately I haven't been able to use it. Sometimes the difference between a 3mb or 300mb install file is worth it if it means that the software is available to more users. In that sense it can be in the user's interest.

> Maybe that already exists?

The closest thing that exists is probably this: https://platform.uno

I don’t have hands-on experience though, only read their web site and watched a couple of videos.

And I’m not sure they have live visual debugger, it might work on Windows when using Visual Studio 2019, but I would be very surprised if they ported that to the rest of them, it‘s relatively hard to accomplish.

There's tons of easy ways to develop gui apps, many easier than Electron. tk and Racket come to mind.

I have nothing against TK or Racket. I haven’t used these two in particular, but I used equivalents like Windows Forms or wxWidgets, and I was happy with both. However, they only work when you don’t have high bar for visual quality, are happy with stock OS-provided controls with minimal customizations, and don’t have too much GUI in general.

GP mentioned styling and visual debugger.

Styling is needed for projects where you have a professionally-made GUI design on input (i.e. Photoshop or Illustrator or XD, or much less often non-Adobe equivalents), and want to make GUI close to that design. Such projects often include custom UX in addition to custom GUI, like animated transitions or decent touch screen integration for custom controls.

Similarly, visual debuggers are only needed when you have very complex GUI, and/or non-trivial UX code.

Other typical requirements for high-quality GUI are internationalization (Unicode all the way down including these surrogate pairs and ideally colored fonts, support for right-to-left languages), and good DPI scaling (this requires vector graphics for assets instead of bitmaps).

I don’t like Electron nor JavaScript, but I have to admit they are often the best tool for the job.

QT is close, but requires C++ with all the unsafe shenanigans, and depending on the project the license can be expensive.

Qt can be developed with Python or JavaScript too. And there are other third party bindings available. [1]

[1] https://wiki.qt.io/Language_Bindings

Reminds me of MLDonkey which has a comparable feature set. It too is still maintained and it also clocks in at around 3 MiB.

All of this while being written mostly in a strongly typed, functional, ML-like high level language.

> ML-like high level language

Calling OCaml an ML-like language is like calling Common Lisp Lisp-like; it is literally the main ML these days with SML a distant second.

Wonder if rust ranks in there, it has a very ML-feel. Considering mindshare/Jobs/Developers.

I would call Rust ML-inspired. I would call OCaml a ML-descendent.

While I completely I agree, I believe the appeal of electron comes from being easily cross platform with a single and consistent UI and most of the code being shared between platforms. I don't know of many stable frameworks that can achieve that while being able to easily create decent looking UIs. The only other one I saw was JavaFx. But even then, you will still need separate codebases for web and native.

Interestingly enough, there's aMule (http://www.amule.org/) which is almost the same as eMule but using wxWidgets, making it cross platform. Just launched it and downloaded a bunch of things, and it sits on 64mb mem and around 2% CPU.

Ain't it ironic? From all the excellent desktop oriented frameworks we have, developers and users seem to prefer cross-platform compatibility that web techologies enable. Consistent UX seems to be winning over all the technological superiority, performance, or personal preferences that developers have. And I don't like the CPU hogging Electron apps too.

> developers and users seem to prefer cross-platform compatibility that web techologies enable

Users don't care about the technology under the hood, and the compatibility can be achieved in any number of ways not just one bloated framework. Developers use this because it makes their life and job easier. But it's still the users who foot the bill one way or another.

It's as compromised as basing every road vehicle on an 18-wheeler platform because this provides the compatibility between all transportation types, a truck can be used for commuting but a subcompact can't be used for freight. Then you ask the drivers to foot the bill for the extra resource consumption or adjusting the infrastructure to accommodate the new and improved "cross-platform" vehicle.

Users aren’t being asked what they prefer, companies are forcing Electron web tech on users without giving them a choice. Example: 1Password just announced a beta Linux client, and it’s going to be Electron. Were users polled about this?

Do users really care about cross platform (as in Windows, OS X, Linux, not Desktop/mobile) consistency?

I believe a lot of the appeal of electron is that e.g. Linux users gets a version at all, which they wouldn't for plenty of products if it would have to be custom built. Most users don't constantly switch the OS platform, consistency across OSes is of little importance to them.

Most users don't have to switch between platforms but those who are obligated to do like I was, consistency cross-platform is removing a level of friction. Most of the time $work provides me Windows and I run my personal laptops on Linux (mostly Fedora) for the last 10 years. Some of my colleagues were running OS X. It was messy to switch context all the time to explain, learn or replicate stuffs when you are not in a IT/SE environment or even tech-savvy places. One lab we had people on Windows/OS X/various Linux distributions for office desktops and calculation servers on Linux distributions. When software are not consistent across platforms, it results on a lot of friction and lost time in meaningless conversations about "How to do X/Y".

The only time I am ok with inconsistent cross-platform is between desktop/mobile because the UX and means of interaction are fundamentally different.

Electron is a middle ground (that if I can avoid it is better) but sometimes ease to use prevail on ressource-hungry applications. The other alternatives (imgui, vulkan, etc.) seems complicated at best and I am not familiar in of with GTK/Qt port on Windows/OS X to know if they are a pain in the ass to develop with.

That's a good point, developers/sysadmins/IT and adjacent jobs in general may be a sizable exception.

Most "normal" users are usually running very homogeneous systems (the average office worker doesn't get to choose whether they want a Mac Book, a Windows PC or a Linux workstation), where the difference would only be between work & private computer use - but I think, most people (again, developers and maybe designers excluded) have little overlap in the tools they use at work and at home.

Electron is the native-ish sequel to the everything-is-a-web-app movement, I suppose. That has similar motivations (also makes everything no-install, super portable), and for plenty of tasks it's good enough, as computers these days are massively over-powered for lots of general tasks.

You get a lot of mileage out of platform-native UI elements. Also, people have been making megabyte-sized icons these days.

I raised a ticket with Slack when I tried to upload a team-icon. They wanted a _minimum_ of 512px^2. For an icon that will never be larger than 64px^2. They told that was intentional but didn't explain why (I guess the ticket handler just didn't know why) Wtf.

That's for "retina" displays. I don't think there are any 8x displays right now, but probably they want to be future-proof for a while

> That's for "retina" displays. I don't think there are any 8x displays right now, but probably they want to be future-proof for a while

It's kinda unreasonable to put restrictions on the users in order to achieve that. I mean, your slack team might not even be around by the time such displays are introduced. Why force the users to jump through hoops for such a silly reason? 90% of the time they're just going to resize whatever image they have in the quickest, dirtiest way to meet the system's arbitrary requirements.

> They wanted a _minimum_ of 512px^2.

It seems like there's a pretty simple malicious-compliance solution for your problem...

Bonus points for using http://jpegify.me/

As others pointed out, this is for future-proof high-dpi monitors. A smarter approach would be to ask for it in a vector format with hints for specific resolutions.

To have a hi-res version available for (future) hidpi screens and to apply their own (optimized?) scaling algorithms to.

Presumably because the icon will be shown on high-dpi displays (retina screens etc), no?

I think it's remarkable that you think it's remarkable ;-)

eMule comes from an era when all applications were native and 1GB of RAM was considered extravagant.

Am era when you could download whatever software you wanted to your device without going through a draconian app store.

An era without walled gardens.

People had websites and blogs.

The technology was bolder. The algorithms used to accomplish heavy lifting were cooler.

It was the wild west and it was free and exciting.

Today we live in a plastic, enterprise, software as a service monoculture. The wild and free part died.

Maybe I'm just getting old, but I hate it.

Your comment reads like the first few lines of a manifesto I'd gladly sign.

My comment was a bit rhetorical but I do remember that period well, as a regular user of DC++, uTorrent, Kazaa and others. It's just that the contrast hits you fresh in the face after several years of getting used to bloated web, .NET, UWP, flatpak apps, it is refreshing to install a full-fledged application consisting of a single binary less than 3 Mb, and whose UI doesn't treat me like I'm a mobile-totting child.

I wish we had more programs like this. They could breathe new life into older or less powerful systems, and get along better with multi-tasking (using several simultaneous Electron apps on a small or mid-tier system brings it to its knees while these computers would still be considered insanely powerful just a decade and a half back).

Hey, don’t hate on .NET!

Windows Vista and up shipped with .NET 3 and .NET 2.0 was a one-time install for Windows XP that enabled devs to ship complete GUI applications with network, file system support, OS integration, COM integration, and more in a single 100KB binary.

UWP is, of course, a different story.

uTorrent comes to mind, when it first came out people where mostly running Azureus and 90% of the network switched over within weeks. Can't beat a single file distribution of under 1MB.

Apparently the benefit of having larger size apps is the higher development flexibility and evolutivity.

There will always be somebody complaining that they prefer JS to C/C++.

Meanwhile if API and language tools were better designed from the start, and we could agree to DUMP HTML and its ecosystem, maybe things would improve.

I guess android is a huge victim of app cruft. I love android but I have to admit software bloat is a real threat to the environment.

HTML is not really the problem. It is overkill if you don't use DOM at least in basic way. To render static non interactive blocks it's better to use straight opengl, and probably easier no matter if you know opengl beforehand.

Electron ships and keeps in memory things almost everybody already has either installed themselves beforehand or laying in main browser cache (JavaScript libraries). A better, but slightly less user friendly alternative would be to ship applications that simply serve the same HTML on a local port and access it through main browser (like syncthing for one example) and perform computing on the local backend server. And here's the main issue: average Joe is scared by :8080 suffix in the browser. The average user is just a step away from the solution but that's... still not there.

Can someone explain to me why don't browsers offer a "local app" mode where they couple with a locally run server and display a more stripped down UI (no favbar, tabs, extensions, etc) for these cases? Is it about security?

Because even HTTP and the server side are growing in complexity. User expectations that browsers are the outside world and the aversion to full page loads are big factors.

But a stripped down UI serves to make a non-tech savvy user not associate it with their usual browsing.

I know server software is getting complex as well, but to my (limited) understanding the interface was the biggest offender when it comes to unnecessary use of resources, which is the problem my proposition tries to solve.

Chrome and Firefox did have this in Debian repos at one point

It also helps that the code is built on top of MFC and targets only a single operating system (Windows).

amule is not that much heavier. [https://github.com/amule-project/amule]

They’re just native