41–50 of 268 posts
There was about a year and a half worth of security work done on Electron (particularly targeting the Node integration and how Node APIs were exposed). I worry that not a lot of people know just how insecure Electron apps used to be, and would generally worry that new Electron frameworks not designed specifically to be secure are going to recapitulate a lot of that.
Earlier quoted context omitted.
It is not a mostly solved problem. The people behind Slack, Spotify, and so on have actually commented on these threads explaining the exact line of reasoning. This stuff isn't limited to just CSS, and it makes total business sense to avoid it.
I don't consider Slack and Spotify to be good at making applications (despite their popularity). These are the least efficient chat app and least efficient music app ever, in a multi-decade history of chat and music apps, which didn't have the overflowing abundance of convenience and productivity offered by Electron. (This is like the obviously silly quote "we lose money on every sale, but we'll make it up in volume!…
Which 99% of users never care about. The idea that large memory usage is a negative business driver is almost laughable at this point, yet for some reason it is a huge pet peeve among lots of technologists.
Earlier quoted context omitted.
It is not a mostly solved problem. The people behind Slack, Spotify, and so on have actually commented on these threads explaining the exact line of reasoning. This stuff isn't limited to just CSS, and it makes total business sense to avoid it.
Maybe I'm just spoiled having doing web dev back in the netscape 4 era when things were _really_ bad. These days it seems like a reset stylesheet and a couple polyfills and you're good to go. I don't doubt that certain problem spaces still run into major cross browser issues, but I guess I've been lucky enough to avoid those problems for the last couple of years.
The desire to use new features as soon as possible is driver enough I feel. Imagine having to wait years for parity between 6 different operating systems before being able to use classes, a language feature introduced years ago and that still isn't fully supported today.
Earlier quoted context omitted.
I don't consider Slack and Spotify to be good at making applications (despite their popularity). These are the least efficient chat app and least efficient music app ever, in a multi-decade history of chat and music apps, which didn't have the overflowing abundance of convenience and productivity offered by Electron. (This is like the obviously silly quote "we lose money on every sale, but we'll make it up in volume!…
> These are the least efficient chat app and least efficient music app ever Which 99% of users never care about. The idea that large memory usage is a negative business driver is almost laughable at this point, yet for some reason it is a huge pet peeve among lots of technologists.
I partly manage a team of end-user support people, and the number of tickets they get with "my computer is slow!" is astonishing.
The number of times it's found that they have Slack eating over half the RAM of their corporate-issued laptop (read: wimpy specs) is huge.
The number of people who understand that Slack being an insane resource hog is a large part of what is making their daily computing business painful is the inverse.
Earlier quoted context omitted.
I don't consider Slack and Spotify to be good at making applications (despite their popularity). These are the least efficient chat app and least efficient music app ever, in a multi-decade history of chat and music apps, which didn't have the overflowing abundance of convenience and productivity offered by Electron. (This is like the obviously silly quote "we lose money on every sale, but we'll make it up in volume!…
> These are the least efficient chat app and least efficient music app ever Which 99% of users never care about. The idea that large memory usage is a negative business driver is almost laughable at this point, yet for some reason it is a huge pet peeve among lots of technologists.
The only debatable question is whether the exact memory overhead (of electron for example) on the specific user machines existing out there today will make a noticeable loading time or lag difference. For many users it seems it does, not everyone has the lastest hardware.
There was about a year and a half worth of security work done on Electron (particularly targeting the Node integration and how Node APIs were exposed). I worry that not a lot of people know just how insecure Electron apps used to be, and would generally worry that new Electron frameworks not designed specifically to be secure are going to recapitulate a lot of that.
There was about a year and a half worth of security work done on Electron (particularly targeting the Node integration and how Node APIs were exposed). I worry that not a lot of people know just how insecure Electron apps used to be, and would generally worry that new Electron frameworks not designed specifically to be secure are going to recapitulate a lot of that.
What is the attack vector that this protects against? Electron apps don't usually just run user-provided code off the internet? They just run the code provided by the app vendor?
Earlier quoted context omitted.
I don't consider Slack and Spotify to be good at making applications (despite their popularity). These are the least efficient chat app and least efficient music app ever, in a multi-decade history of chat and music apps, which didn't have the overflowing abundance of convenience and productivity offered by Electron. (This is like the obviously silly quote "we lose money on every sale, but we'll make it up in volume!…
> These are the least efficient chat app and least efficient music app ever Which 99% of users never care about. The idea that large memory usage is a negative business driver is almost laughable at this point, yet for some reason it is a huge pet peeve among lots of technologists.
These projects completely overlook _why_ people choose Electron over the system view. - Nobody wants to be testing against multiple browser/rendering engines in 2019. - Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately. Edit: Since I can already see the litany of armchair-quarterback-desktop-app-authors, I'm just going to link to the comment from…
This is like claiming nobody wants to write C because no one wants to manage their own memory in 2019, or miss out on all the cool new packages in the JS ecosystem.
Evidently _some people_ do. I can assure you there's at least number _n > 1_ of people who care more about app size than either of your points.
I personally wrote a side project in system web-view, because I don't want my macOS-only system-tray application to weigh 115+MB to make sure I have APIs I don't need in platforms I don't support.