6 ms·

So much fighting over how best to draw the UI that will launch various instances of the Chrome engine. Want to know why everything is written in Electron or as

So much fighting over how best to draw the UI that will launch various instances of the Chrome engine. 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.

morsch 5y ago
And then the calculator app, which is native, is wrapped up in some sort of isolating container that makes it take as long to start up as an electron app.
- schipplock 5y ago
  I sometimes, by accident, launched LibreOffice Calc. It launched faster than the calculator app :). I believe they changed that. The calculator app isn't shipped in a snap package anymore.
- supramouse 5y ago
  you mean snap packages? I think the calculator is written in vala was pretty performant when I've used it the past
- sph 5y ago
  You're using the wrong isolating container ;) There's only one that is quite slow at startup, the other isn't.
  - nix23 5y ago
    Just imagine you need a container for the calculator.....
    - sph 5y ago
      Just imagine getting pwned by malware bundled in a calculator...
      - nix23 5y ago
        What is the connection here? Why would you install the calculator not coming from your distribution?
        sph 5y ago
        Because there is a push for software developers to be able to package directly for end users. Without devolving into the usual flame war of whether it's a good idea or not, once you install any piece of software you incur some security risks. It's not like distro maintainers are a 100% guarantee there won't be a backdoor in the binary, and compiling software from source doesn't free you from risks either, unless you code-review everything you install. 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.
        nix23 5y ago
        That's not what i asked, why do you trust a no name dev more then the distro your kernel is coming from? And do you really think flatpack prevents you from running packed malware?
        wander_homer 5y ago
        Why do you assume the flatpak comes from a no name dev? My calculator flatpak comes from the same people who wrote it, and I obviously trust them, otherwise I wouldn't be using their application. So why should I trust them less than my distribution?
        5y ago
    - rollcat 5y ago
      OpenBSD went that route, and when they introduced pledge(2) and later unveil(2), they've applied these to every single program in the base system (over the course of a single release cycle!). 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/pledge; https://man.openbsd.org/unveil https://man.openbsd.org/unveil
      - nix23 5y ago
        you really compare something like pledge and unveil with flatpack and snap's? Completely different goal's...
        rollcat 5y ago
        I don't think the security goals are that different, but you've asked why would I want to sandbox a calculator. Well - why would I not want that?
        nix23 5y ago
        Look, you gave the openbsd example, and that's the right way to do it. 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.
        throwaway82652 5y ago
        Pledge is a bad example, it isn't applied to a lot of packages in the ports tree and it's infeasible to do it for every program. In the end you'll find you end up with the same situation as Linux: another layer on top with daemons implementing blanket security policies using pledge on behalf of the programs. Kind of like... a sandbox. 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.
    - ducktective 5y ago
      username checks out ;)
kelnos 5y ago
I don't think that's really the reason for Electron's popularity. While GTK and Qt are cross-platform, my (limited, to be fair) experience with building for multiple platforms was that it was a huge pain in the ass, and Windows and macOS platform integration often felt clunky and out of place. 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.
- smegsicle 5y ago
  a big part of why browser engines are so unwieldy is the implied compatibility with every website ever, right? 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?
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - wffurr 5y ago
    That's a really interesting idea, but in practice you might find that the "conservative sunset" ends up being different for every toolkit and developer. 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?
skeletal88 5y ago
Qt has stayed the same and KDE has been excellent, this is a probleem with GTK and Gnome based desktops
imtringued 5y ago
I once installed Linux with Gnome 3 on a USB stick and used that as my primary operating system for six months. My number one application was a web browser. I don't think I ever bothered installing anything other than code editors, language runtimes/compilers and steam. Gnome works just fine. 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.
Bancakes 5y ago
Rhetorical question? It's cheap and quick. Can be outsourced to the lowest lifeform that legitimately describes itself as a programmer.

morsch 5y ago

And then the calculator app, which is native, is wrapped up in some sort of isolating container that makes it take as long to start up as an electron app.

schipplock 5y ago
I sometimes, by accident, launched LibreOffice Calc. It launched faster than the calculator app :). I believe they changed that. The calculator app isn't shipped in a snap package anymore.
supramouse 5y ago
you mean snap packages? I think the calculator is written in vala was pretty performant when I've used it the past
sph 5y ago
You're using the wrong isolating container ;) There's only one that is quite slow at startup, the other isn't.
- nix23 5y ago
  Just imagine you need a container for the calculator.....
  - sph 5y ago
    Just imagine getting pwned by malware bundled in a calculator...
    - nix23 5y ago
      What is the connection here? Why would you install the calculator not coming from your distribution?
      - sph 5y ago
        Because there is a push for software developers to be able to package directly for end users. Without devolving into the usual flame war of whether it's a good idea or not, once you install any piece of software you incur some security risks. It's not like distro maintainers are a 100% guarantee there won't be a backdoor in the binary, and compiling software from source doesn't free you from risks either, unless you code-review everything you install. 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.
        nix23 5y ago
        That's not what i asked, why do you trust a no name dev more then the distro your kernel is coming from? And do you really think flatpack prevents you from running packed malware?
        wander_homer 5y ago
        Why do you assume the flatpak comes from a no name dev? My calculator flatpak comes from the same people who wrote it, and I obviously trust them, otherwise I wouldn't be using their application. So why should I trust them less than my distribution?
        5y ago
  - rollcat 5y ago
    OpenBSD went that route, and when they introduced pledge(2) and later unveil(2), they've applied these to every single program in the base system (over the course of a single release cycle!). 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/pledge; https://man.openbsd.org/unveil https://man.openbsd.org/unveil
    - nix23 5y ago
      you really compare something like pledge and unveil with flatpack and snap's? Completely different goal's...
      - rollcat 5y ago
        I don't think the security goals are that different, but you've asked why would I want to sandbox a calculator. Well - why would I not want that?
        nix23 5y ago
        Look, you gave the openbsd example, and that's the right way to do it. 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.
        throwaway82652 5y ago
        Pledge is a bad example, it isn't applied to a lot of packages in the ports tree and it's infeasible to do it for every program. In the end you'll find you end up with the same situation as Linux: another layer on top with daemons implementing blanket security policies using pledge on behalf of the programs. Kind of like... a sandbox. 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.
  - ducktective 5y ago
    username checks out ;)

kelnos 5y ago

I don't think that's really the reason for Electron's popularity. While GTK and Qt are cross-platform, my (limited, to be fair) experience with building for multiple platforms was that it was a huge pain in the ass, and Windows and macOS platform integration often felt clunky and out of place. 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.

smegsicle 5y ago
a big part of why browser engines are so unwieldy is the implied compatibility with every website ever, right? 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?
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- wffurr 5y ago
  That's a really interesting idea, but in practice you might find that the "conservative sunset" ends up being different for every toolkit and developer. 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?

skeletal88 5y ago

Qt has stayed the same and KDE has been excellent, this is a probleem with GTK and Gnome based desktops

imtringued 5y ago

I once installed Linux with Gnome 3 on a USB stick and used that as my primary operating system for six months. My number one application was a web browser. I don't think I ever bothered installing anything other than code editors, language runtimes/compilers and steam. Gnome works just fine. 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.

Bancakes 5y ago

Rhetorical question? It's cheap and quick. Can be outsourced to the lowest lifeform that legitimately describes itself as a programmer.