7 ms·

On a related note, it is remarkable how a program that does several things and deals with more than one network protocol and presents a complex, information-ric

On a related note, it is remarkable how a program that does several things and deals with more than one network protocol and presents a complex, information-rich, configurable interface can still clock in at about 3 megabytes. I can't help thinking an Electron version of this would be about 250Mb and have 1/4th functionality and consume 1 Gb of memory just idling.

rbanffy 6y ago
You get a lot of mileage out of platform-native UI elements. Also, people have been making megabyte-sized icons these days.
- Jestar342 6y ago
  I raised a ticket with Slack when I tried to upload a team-icon. They wanted a _minimum_ of 512px^2. For an icon that will never be larger than 64px^2. They told that was intentional but didn't explain why (I guess the ticket handler just didn't know why) Wtf.
  - indeyets 6y ago
    That's for "retina" displays. I don't think there are any 8x displays right now, but probably they want to be future-proof for a while
    - ardy42 6y ago
      > That's for "retina" displays. I don't think there are any 8x displays right now, but probably they want to be future-proof for a while 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.
  - unglaublich 6y ago
    To have a hi-res version available for (future) hidpi screens and to apply their own (optimized?) scaling algorithms to.
  - allover 6y ago
    Presumably because the icon will be shown on high-dpi displays (retina screens etc), no?
  - rbanffy 6y ago
    As others pointed out, this is for future-proof high-dpi monitors. A smarter approach would be to ask for it in a vector format with hints for specific resolutions.
  - dane-pgp 6y ago
    > They wanted a _minimum_ of 512px^2. It seems like there's a pretty simple malicious-compliance solution for your problem... Bonus points for using http://jpegify.me/ http://jpegify.me/
jokoon 6y ago
Apparently the benefit of having larger size apps is the higher development flexibility and evolutivity. 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.
- loa_in_ 6y ago
  HTML is not really the problem. It is overkill if you don't use DOM at least in basic way. To render static non interactive blocks it's better to use straight opengl, and probably easier no matter if you know opengl beforehand. 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.
  - farias0 6y ago
    Can someone explain to me why don't browsers offer a "local app" mode where they couple with a locally run server and display a more stripped down UI (no favbar, tabs, extensions, etc) for these cases? Is it about security?
    - paulryanrogers 6y ago
      Because even HTTP and the server side are growing in complexity. User expectations that browsers are the outside world and the aversion to full page loads are big factors.
      - farias0 6y ago
duiker101 6y ago
While I completely I agree, I believe the appeal of electron comes from being easily cross platform with a single and consistent UI and most of the code being shared between platforms. I don't know of many stable frameworks that can achieve that while being able to easily create decent looking UIs. The only other one I saw was JavaFx. But even then, you will still need separate codebases for web and native.
- high_5 6y ago
  Ain't it ironic? From all the excellent desktop oriented frameworks we have, developers and users seem to prefer cross-platform compatibility that web techologies enable. Consistent UX seems to be winning over all the technological superiority, performance, or personal preferences that developers have. And I don't like the CPU hogging Electron apps too.
  - buran77 6y ago
    > developers and users seem to prefer cross-platform compatibility that web techologies enable 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.
  - luckylion 6y ago
    Do users really care about cross platform (as in Windows, OS X, Linux, not Desktop/mobile) consistency? 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.
weinzierl 6y ago
Reminds me of MLDonkey which has a comparable feature set. It too is still maintained and it also clocks in at around 3 MiB. All of this while being written mostly in a strongly typed, functional, ML-like high level language.
- LeonidasXIV 6y ago
  > 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.
  - ysleepy 6y ago
    Wonder if rust ranks in there, it has a very ML-feel. Considering mindshare/Jobs/Developers.
    - smabie 6y ago
      I would call Rust ML-inspired. I would call OCaml a ML-descendent.
q3k 6y ago
It also helps that the code is built on top of MFC and targets only a single operating system (Windows).
- tgragnato 6y ago
  amule is not that much heavier. [https://github.com/amule-project/amule https://github.com/amule-project/amule] They’re just native
userbinator 6y ago
I think it's remarkable that you think it's remarkable ;-) eMule comes from an era when all applications were native and 1GB of RAM was considered extravagant.
- aeyes 6y ago
  uTorrent comes to mind, when it first came out people where mostly running Azureus and 90% of the network switched over within weeks. Can't beat a single file distribution of under 1MB.
- echelon 6y ago
  Am era when you could download whatever software you wanted to your device without going through a draconian app store. 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.
  - deleted 6y ago
    [deleted]
  - HeckFeck 6y ago
    Your comment reads like the first few lines of a manifesto I'd gladly sign.
- Santosh83 6y ago
  My comment was a bit rhetorical but I do remember that period well, as a regular user of DC++, uTorrent, Kazaa and others. It's just that the contrast hits you fresh in the face after several years of getting used to bloated web, .NET, UWP, flatpak apps, it is refreshing to install a full-fledged application consisting of a single binary less than 3 Mb, and whose UI doesn't treat me like I'm a mobile-totting child. 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).
deleted 6y ago
[deleted]
gfxgirl 6y ago
When someone makes a platform as easy to use as Electron that makes tiny executables with zero friction and lets me easily style and debug a live running app I'll switch. Maybe that already exists? 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 Then I ssh to a linux box, clone the repo and npm i ./node_modules/.bin/electron-builder Then I ssh to a windows box, clone the repo and do exactly the same thing. 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.
- Const-me 6y ago
  > Maybe that already exists? The closest thing that exists is probably this: https://platform.uno 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.
  - deleted 6y ago
    [deleted]
- buran77 6y ago
  > with zero friction and lets me easily 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.

rbanffy 6y ago

You get a lot of mileage out of platform-native UI elements. Also, people have been making megabyte-sized icons these days.

Jestar342 6y ago
I raised a ticket with Slack when I tried to upload a team-icon. They wanted a _minimum_ of 512px^2. For an icon that will never be larger than 64px^2. They told that was intentional but didn't explain why (I guess the ticket handler just didn't know why) Wtf.
- indeyets 6y ago
  That's for "retina" displays. I don't think there are any 8x displays right now, but probably they want to be future-proof for a while
  - ardy42 6y ago
    > That's for "retina" displays. I don't think there are any 8x displays right now, but probably they want to be future-proof for a while 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.
- unglaublich 6y ago
  To have a hi-res version available for (future) hidpi screens and to apply their own (optimized?) scaling algorithms to.
- allover 6y ago
  Presumably because the icon will be shown on high-dpi displays (retina screens etc), no?
- rbanffy 6y ago
  As others pointed out, this is for future-proof high-dpi monitors. A smarter approach would be to ask for it in a vector format with hints for specific resolutions.
- dane-pgp 6y ago
  > They wanted a _minimum_ of 512px^2. It seems like there's a pretty simple malicious-compliance solution for your problem... Bonus points for using http://jpegify.me/ http://jpegify.me/

jokoon 6y ago

Apparently the benefit of having larger size apps is the higher development flexibility and evolutivity. 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.

loa_in_ 6y ago
HTML is not really the problem. It is overkill if you don't use DOM at least in basic way. To render static non interactive blocks it's better to use straight opengl, and probably easier no matter if you know opengl beforehand. 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.
- farias0 6y ago
  Can someone explain to me why don't browsers offer a "local app" mode where they couple with a locally run server and display a more stripped down UI (no favbar, tabs, extensions, etc) for these cases? Is it about security?
  - paulryanrogers 6y ago
    Because even HTTP and the server side are growing in complexity. User expectations that browsers are the outside world and the aversion to full page loads are big factors.
    - farias0 6y ago

duiker101 6y ago

While I completely I agree, I believe the appeal of electron comes from being easily cross platform with a single and consistent UI and most of the code being shared between platforms. I don't know of many stable frameworks that can achieve that while being able to easily create decent looking UIs. The only other one I saw was JavaFx. But even then, you will still need separate codebases for web and native.

high_5 6y ago
Ain't it ironic? From all the excellent desktop oriented frameworks we have, developers and users seem to prefer cross-platform compatibility that web techologies enable. Consistent UX seems to be winning over all the technological superiority, performance, or personal preferences that developers have. And I don't like the CPU hogging Electron apps too.
- buran77 6y ago
  > developers and users seem to prefer cross-platform compatibility that web techologies enable 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.
- luckylion 6y ago
  Do users really care about cross platform (as in Windows, OS X, Linux, not Desktop/mobile) consistency? 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.

weinzierl 6y ago

Reminds me of MLDonkey which has a comparable feature set. It too is still maintained and it also clocks in at around 3 MiB. All of this while being written mostly in a strongly typed, functional, ML-like high level language.

LeonidasXIV 6y ago
> 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.
- ysleepy 6y ago
  Wonder if rust ranks in there, it has a very ML-feel. Considering mindshare/Jobs/Developers.
  - smabie 6y ago
    I would call Rust ML-inspired. I would call OCaml a ML-descendent.

q3k 6y ago

It also helps that the code is built on top of MFC and targets only a single operating system (Windows).

tgragnato 6y ago
amule is not that much heavier. [https://github.com/amule-project/amule https://github.com/amule-project/amule] They’re just native

userbinator 6y ago

I think it's remarkable that you think it's remarkable ;-) eMule comes from an era when all applications were native and 1GB of RAM was considered extravagant.

aeyes 6y ago
uTorrent comes to mind, when it first came out people where mostly running Azureus and 90% of the network switched over within weeks. Can't beat a single file distribution of under 1MB.
echelon 6y ago
Am era when you could download whatever software you wanted to your device without going through a draconian app store. 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.
- deleted 6y ago
  [deleted]
- HeckFeck 6y ago
  Your comment reads like the first few lines of a manifesto I'd gladly sign.
Santosh83 6y ago
My comment was a bit rhetorical but I do remember that period well, as a regular user of DC++, uTorrent, Kazaa and others. It's just that the contrast hits you fresh in the face after several years of getting used to bloated web, .NET, UWP, flatpak apps, it is refreshing to install a full-fledged application consisting of a single binary less than 3 Mb, and whose UI doesn't treat me like I'm a mobile-totting child. 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).

deleted 6y ago

[deleted]

gfxgirl 6y ago

When someone makes a platform as easy to use as Electron that makes tiny executables with zero friction and lets me easily style and debug a live running app I'll switch. Maybe that already exists? 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 Then I ssh to a linux box, clone the repo and npm i ./node_modules/.bin/electron-builder Then I ssh to a windows box, clone the repo and do exactly the same thing. 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.

Const-me 6y ago
> Maybe that already exists? The closest thing that exists is probably this: https://platform.uno 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.
- deleted 6y ago
  [deleted]
buran77 6y ago
> with zero friction and lets me easily 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.