The big draw for Electron is that we have way way way more web developers out there these days than native-code desktop UI developers, so it's easy to leverage those people and get results fairly quickly, even if the resulting apps don't really conform to any desktop's standard look-and-feel (which I guess avoids the uncanny valley effect of cross-platform toolkits that try to be native, but fail in subtle and not-so-subtle ways). People can even just (sorta) repackage their existing webapp, and end up with more or less a single code base for all desktop platforms + web.
I do agree with you that most of the desktop platforms are pretty annoying to develop for if you want a solid, stable base, but I don't think that's the prevailing reason for Electron's uptake.
but the "way way more web developers" you mention are not, at least in the context of electron apps, interested in that feature except tangentially..
so while everyone knows a full web-ready browser engine is impractical to design from scratch, maybe a simplified engine that supports a conservative subset of best-practices web-style design is in order?
The issue here is re-use - Sciter is small and very fast, but won’t run an arbitrary existing web app that targets Chrome. Maybe you could argue for a middler-ground, add more HTML features to Sciter until it can run “most” things… but you’ll end up back to having the whole banana.
Maybe something a bit opinionated, like a React Native-only runtime, could fit the bill here.
Or in a sense, is this what Flutter is?
There's absolutely zero reason for bc(1) to accept network connections, or for grep(1) to execve(2) into arbitrary programs. But both of these programs need to process and interpret arbitrary input, which makes them potential targets for exploits.
You don't technically "need" security, just like you don't "need" seatbelts... until you actually are in an accident.
https://man.openbsd.org/pledge; https://man.openbsd.org/unveil
Flatpack's are for packaged software-deployment, those are two different things.
Why the need for a sandbox if you could do it much cleaner with things like pledge? But in typical linux fashion, just put another layer on top the pile of garbage so it stop's to stink for a while.
>Well - why would I not want that?
Then please start with the most obvious application sometimes called kernel.
Instead of rigorously integrate something like SElinux they throw layers over layers of half-backed "sandboxes", up to the point to separate applications with Xen (Qube-os), then you find out about Meltdown, and we are back in 1990.
SELinux is also a bad example, even if you decide you're using that as the underlying technology you still need to implement a sandbox with various on top of it. SELinux does nothing without those rules.
No why? If you have the right (and correct) rules, SELinux absolutely act's as a "sandbox", that's exactly what i meant, a sandbox don't need's to be another layer of software. Run in your "namespace", can just create/access/execute/read your port, files, memory..that's it, that's a sandboxed application.
For example that "namespace-sandbox" is standard in Plan9/9front...without any additional software, just the filesystem and 9p.
https://dwalsh.fedorapeople.org/SELinux/Presentations/sandbo...
>For example that "namespace-sandbox" is standard in Plan9/9front...without any additional software, just the filesystem and 9p.
This is what I mean, Plan9 style mount namespaces are also available in Linux and are preferable to SELinux for containers and sandboxes because they're actually simpler and less trouble.
Hell YES...high five!! ;)
My point is, containerisation on Linux isn't necessarily slow—in fact it's unnoticeable if implemented correctly—and I prefer to default to having a decent amount of security by containerising as much software as I can, whatever the origin. Including, and especially software like the calculator, since it should not be able to do anything more than show a GUI and add numbers together.
So why should I trust them less than my distribution?
Just use google -> npm malware
With my calculator flatpak I only have to trust one person and to a much lesser degree, because they declared that the calculator can't access my personal files to begin with. The same app in my distribution repository has full read-write access to all my users files, network access and much more. So yeah, I trust it more.
Distribution maintainers are nothing but a middle man, which don't even audit the code they package, so there's nothing I gain from them.
Without flatpak I'd need to use some rolling release distribution, where not just a few applications get updated quickly, but also the rest of the system, which I'm not interested in.
The only annoyance was the breakage that Wayland introduced in 2016. Suddenly you couldn't screen capture the whole screen anymore. It's kinda the same issue as switching from python 2 to 3 but the difference here is that it is a major upgrade that is worth the effort. The reasons why python 3 isn't backwards compatible are incredibly petty for the most part. However, firefox has received Wayland support for screensharing and some people developed a plugin for OBS. Wayland works just fine now too.
Want to know why everything is written in Electron or as a web app? Because literally every desktop platform over the last decade has decided to play design and engineering games instead of just make a really solid stable base to write apps on top of.