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
npm i
./node_modules/.bin/electron-builder
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.
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.
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.
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.
All of this while being written mostly in a strongly typed, functional, 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.
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.
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.
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.
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.
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.
It seems like there's a pretty simple malicious-compliance solution for your problem...
Bonus points for using http://jpegify.me/
eMule comes from an era when all applications were native and 1GB of RAM was considered extravagant.
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.
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).
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.
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.
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.
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.
They’re just native