6 ms·

Making electron, the entire point of which was to lower the barrier to entry to app development, even vaguely reasonable in terms of memory use by having to cod

by weego 7y ago

Making electron, the entire point of which was to lower the barrier to entry to app development, even vaguely reasonable in terms of memory use by having to code in Rust which is very much not low barrier to entry is an irony that strikes exactly to the heart of the point the person was making.

jlongster 7y ago
I don't get what you are saying. Using 230MB of memory for a very data-heavy app is already somewhat reasonable, and more advanced optimizations are going to require more advanced engineering. It's the same thing with any app, as you go further along development you will want to optimize in more advanced ways. I'm not arguing that Electron doesn't have bloat though: https://news.ycombinator.com/item?id=20274725 https://news.ycombinator.com/item?id=20274725
- Scarbutt 7y ago
  I don't understand how is this a "data-heavy" app? You are implying that most of those 230MB is data? I mean, how much data can a user for a personal finance app store in a year?
  - fjp 7y ago
    Every single transaction on every account they have for starters, plus a data point for the total in the account at the end of each day I would imagine, plus all metadata you could ever want to associated with a transaction
    - _dps 7y ago
      Ballpark: say 16 8-byte fields for each transaction and 128 transactions per day, 30 years of transactions is ~180MB. (to be clear I consider this a very generous estimate of how big this could possibly get)
derefr 7y ago
Electron lowers the barrier-to-entry for frontend app development. Or, more cynically: Electron allows you to hire cheaper, less-experienced frontend engineers. A background worker in an Electron process, however, can be thought of (depending on what it’s used for) as more of a “local ambassador of the server”, and thus isn’t really “frontend” at all. It lands on the client, sure, but it’s no more frontend than the client-side half of the Firebase library is frontend. It’s plumbing, and so it’d be the responsibility of a backend or infrastructure engineer to write and maintain. If you take this perspective, you still receive the main practical advantage that the system’s product manager was probably seeking by choosing Electron in the first place: the ability to hire inexperienced engineers to do UX tweaks, freeing up the senior engineers’ time to handle the hard stuff. UX tweaks won’t generally bubble down to the level of needing to modify the background worker (again, depending on how you’ve written the thing), so your [junior] frontend engineers won’t need to touch the background worker, so it can be written in a language more on the “good engineering” side of the spectrum than the “low barrier to entry” side—like Rust—without that causing you any headaches of the “everybody who knows how to fix it is busy” variety.
- egeozcan 7y ago
  > Electron allows you to hire cheaper, less-experienced frontend engineers. Do you mean that the front end developers are cheaper or you mean even the less experienced can code in Electron? I have issue with both but I need to understand what you mean first.
  - derefr 7y ago
    I mean that you can hire developers who, due to their inexperience, know just enough to make one very specific kind of thing, and that thing is a certain type of SPA frontend (e.g. "React developers", sort of like "Java developers"). Because they only have this one skill, and because "web SPA frontend developer" is in-demand enough for a decent supply pipeline of them to have formed (of "code bootcamps" et al), the junior ones are relatively cheap to hire. You can then have someone with more experience "box up" that web SPA frontend in an Electron wrapper, in a way that will generally last a good while. (This is, AFAIK, precisely the approach taken by teams like Spotify, where the Electron app has no extra functionality beyond what you'd get from the web app.) Of course, developers generally age out of only having one skill, so this is sort of the programming equivalent of an "intern job": not something anyone would stay in for more than the length of an internship, and something that you just constantly pump new people through.

by weego 7y ago

jlongster 7y ago

I don't get what you are saying. Using 230MB of memory for a very data-heavy app is already somewhat reasonable, and more advanced optimizations are going to require more advanced engineering. It's the same thing with any app, as you go further along development you will want to optimize in more advanced ways. I'm not arguing that Electron doesn't have bloat though: https://news.ycombinator.com/item?id=20274725 https://news.ycombinator.com/item?id=20274725

Scarbutt 7y ago
I don't understand how is this a "data-heavy" app? You are implying that most of those 230MB is data? I mean, how much data can a user for a personal finance app store in a year?
- fjp 7y ago
  Every single transaction on every account they have for starters, plus a data point for the total in the account at the end of each day I would imagine, plus all metadata you could ever want to associated with a transaction
  - _dps 7y ago
    Ballpark: say 16 8-byte fields for each transaction and 128 transactions per day, 30 years of transactions is ~180MB. (to be clear I consider this a very generous estimate of how big this could possibly get)

derefr 7y ago

Electron lowers the barrier-to-entry for frontend app development. Or, more cynically: Electron allows you to hire cheaper, less-experienced frontend engineers. A background worker in an Electron process, however, can be thought of (depending on what it’s used for) as more of a “local ambassador of the server”, and thus isn’t really “frontend” at all. It lands on the client, sure, but it’s no more frontend than the client-side half of the Firebase library is frontend. It’s plumbing, and so it’d be the responsibility of a backend or infrastructure engineer to write and maintain. If you take this perspective, you still receive the main practical advantage that the system’s product manager was probably seeking by choosing Electron in the first place: the ability to hire inexperienced engineers to do UX tweaks, freeing up the senior engineers’ time to handle the hard stuff. UX tweaks won’t generally bubble down to the level of needing to modify the background worker (again, depending on how you’ve written the thing), so your [junior] frontend engineers won’t need to touch the background worker, so it can be written in a language more on the “good engineering” side of the spectrum than the “low barrier to entry” side—like Rust—without that causing you any headaches of the “everybody who knows how to fix it is busy” variety.

egeozcan 7y ago
> Electron allows you to hire cheaper, less-experienced frontend engineers. Do you mean that the front end developers are cheaper or you mean even the less experienced can code in Electron? I have issue with both but I need to understand what you mean first.
- derefr 7y ago
  I mean that you can hire developers who, due to their inexperience, know just enough to make one very specific kind of thing, and that thing is a certain type of SPA frontend (e.g. "React developers", sort of like "Java developers"). Because they only have this one skill, and because "web SPA frontend developer" is in-demand enough for a decent supply pipeline of them to have formed (of "code bootcamps" et al), the junior ones are relatively cheap to hire. You can then have someone with more experience "box up" that web SPA frontend in an Electron wrapper, in a way that will generally last a good while. (This is, AFAIK, precisely the approach taken by teams like Spotify, where the Electron app has no extra functionality beyond what you'd get from the web app.) Of course, developers generally age out of only having one skill, so this is sort of the programming equivalent of an "intern job": not something anyone would stay in for more than the length of an internship, and something that you just constantly pump new people through.