4 ms·

> Nope, just a wrapper Nope, its still a fully fledged client, because being a capable client is not /that/ dependant on the UI rendering method, believe it or

> Nope, just a wrapper Nope, its still a fully fledged client, because being a capable client is not /that/ dependant on the UI rendering method, believe it or not. > but it still has all the disadvantages that you incur when your client is just a web page in a browser. No? Do you think electron exposes absolutely nothing? There is code being executed with access to the rest of your computer, this has the same access as any other language to the rest of your computer, I mean, hell even if you wanna do something weird, you could write some stuff in C (or use the pythonesque ctypes module), and then run that in turn, once again with access to the rest of your computer. I could understand these complaints if this was an important critical thing, but its a chat client, its only job is to display text nicely with formatting, browsers are pretty good at that

Klathmon 10y ago
>its only job is to display text nicely with formatting, browsers are pretty good at This is something that continually amazes me. Many developers seem to think that "display text on a screen" is easy, it's not. Browsers can handle multiple fonts, multiple sizes, and crazy positioning. Browsers can handle tons of different encodings (including stuff like UTF8 which can be a real pain to safely and correctly parse). Browsers can display just about every single glyph on the planet without a sweat. Browsers can handle right-to-left text right alongside left-to-right text (even switching in the same sentence!). Browsers have a simple way to apply multiple fallback fonts (just in case your font of choice doesn't have the unicode 'HEXAGRAM FOR DIFFICULTY AT THE BEGINNING', it can fallback to a font that does). Browser can apply simple CSS transformations to rotate text (even in 3D!) in a pretty performant way. Browsers handle all of this, without the developer needing to spend more than 5 minutes even thinking about it, and it does so looking great. Yeah, other UI libraries can handle most of this just fine as well, but the browser is the one platform that i've been impressed at just how well it handles typography in general. I remember how much of a fight it was to write text that went vertical to label a graph in business basic...
kitsunesoba 10y ago
>but its a chat client That's part of the problem. Electron apps are unavoidably heavy - huge binaries and 250MB-300MB+ memory consumed regardless of the task at hand. A simple "hello world" in electron without an ounce of JS or CSS will exhibit these traits. Chat is a very simple sort of application. We've been doing it for decades now and have had functionality that approaches that of hangouts that works perfectly on machines with tens and hundreds of times less power and resources available. There's barely an excuse for such a program to consume more than 50MB of RAM, let alone 300MB+. Some may argue that "unused RAM is wasted RAM," but I'd argue that this statement holds true only if the RAM that would be used is needed for actual functionality. If it's baseline requirement for the program to run at all, something is wrong unless the program is monstrous in nature (think AutoCAD, Maya, etc).
- kbenson 10y ago
  This is only a useful argument when comparing to an alternative that does not exhibit those traits, otherwise you are saying it's worse than nothing, which it is not. If you want to say this is worse than X (where X is some theoretical desktop hangouts client) because it uses too much RAM, then do so, and we can compare and contrast what that RAM usage gets us in this case, and what the trade off is. If you just want to make a case that the RAM usage is too much for any chat, and if that's the baseline requirement for hangouts on the desktop because there are no other clients without those same problems (?), then you can propose a different protocol which doesn't have those restrictions. If you aren't willing to do any of that, then all you're really doing is telling people not to use a technology because it uses a lot of RAM, on principle, regardless of whether it would be useful to them. I don't think that's a good stance to take.
  - kitsunesoba 10y ago
    >I don't think that's a good stance to take. You're probably right, but it's also no good to sweep the shortcomings of a technology under the rug and forget about them. With Electron and similar web-wrapper technologies becoming more popular, these issues should be put out in the spotlight and consistently pointed out so that they might be addressed. Brushing them aside is a disservice to everyone, developers using Electron included.
    - kbenson 10y ago
      Sure, but presumably the technology was chosen because there were trade-offs and the developers found it worth while. It's the same argument as writing a program in a dynamic language, in Java, or in C/C++ (or any other bare-metal low resource implementation, such as Rust). Complaining about a program being written in Java because it's bloated and used too much memory isn't useful in itself, if there are no better alternatives with respect to those complaints. Pointing out the alternative forces you to think about it more critically. Saying use C++ instead of Java opens you up to thinking about the choice the developer made in using Java. Perhaps it was specifically to avoid some pitfalls in C++, or because it was perceived as easier to work in. Similarly, saying to use Java instead of Python opens you up to those same considerations. All that's really just a long way of saying, maybe the developer decided that using this system accelerated their development enough that it was worth it. It's up to the users to choose to use the program, and if they find the drawbacks of the developer's choices to be not worth it, then they can choose something else (if it exists). If nothing else exists, then maybe the reason the capability exists at this point in the first place is because of those developer choices, in which case it's hard to fault them.

Klathmon 10y ago

>its only job is to display text nicely with formatting, browsers are pretty good at This is something that continually amazes me. Many developers seem to think that "display text on a screen" is easy, it's not. Browsers can handle multiple fonts, multiple sizes, and crazy positioning. Browsers can handle tons of different encodings (including stuff like UTF8 which can be a real pain to safely and correctly parse). Browsers can display just about every single glyph on the planet without a sweat. Browsers can handle right-to-left text right alongside left-to-right text (even switching in the same sentence!). Browsers have a simple way to apply multiple fallback fonts (just in case your font of choice doesn't have the unicode 'HEXAGRAM FOR DIFFICULTY AT THE BEGINNING', it can fallback to a font that does). Browser can apply simple CSS transformations to rotate text (even in 3D!) in a pretty performant way. Browsers handle all of this, without the developer needing to spend more than 5 minutes even thinking about it, and it does so looking great. Yeah, other UI libraries can handle most of this just fine as well, but the browser is the one platform that i've been impressed at just how well it handles typography in general. I remember how much of a fight it was to write text that went vertical to label a graph in business basic...

kitsunesoba 10y ago

>but its a chat client That's part of the problem. Electron apps are unavoidably heavy - huge binaries and 250MB-300MB+ memory consumed regardless of the task at hand. A simple "hello world" in electron without an ounce of JS or CSS will exhibit these traits. Chat is a very simple sort of application. We've been doing it for decades now and have had functionality that approaches that of hangouts that works perfectly on machines with tens and hundreds of times less power and resources available. There's barely an excuse for such a program to consume more than 50MB of RAM, let alone 300MB+. Some may argue that "unused RAM is wasted RAM," but I'd argue that this statement holds true only if the RAM that would be used is needed for actual functionality. If it's baseline requirement for the program to run at all, something is wrong unless the program is monstrous in nature (think AutoCAD, Maya, etc).

kbenson 10y ago
This is only a useful argument when comparing to an alternative that does not exhibit those traits, otherwise you are saying it's worse than nothing, which it is not. If you want to say this is worse than X (where X is some theoretical desktop hangouts client) because it uses too much RAM, then do so, and we can compare and contrast what that RAM usage gets us in this case, and what the trade off is. If you just want to make a case that the RAM usage is too much for any chat, and if that's the baseline requirement for hangouts on the desktop because there are no other clients without those same problems (?), then you can propose a different protocol which doesn't have those restrictions. If you aren't willing to do any of that, then all you're really doing is telling people not to use a technology because it uses a lot of RAM, on principle, regardless of whether it would be useful to them. I don't think that's a good stance to take.
- kitsunesoba 10y ago
  >I don't think that's a good stance to take. You're probably right, but it's also no good to sweep the shortcomings of a technology under the rug and forget about them. With Electron and similar web-wrapper technologies becoming more popular, these issues should be put out in the spotlight and consistently pointed out so that they might be addressed. Brushing them aside is a disservice to everyone, developers using Electron included.
  - kbenson 10y ago
    Sure, but presumably the technology was chosen because there were trade-offs and the developers found it worth while. It's the same argument as writing a program in a dynamic language, in Java, or in C/C++ (or any other bare-metal low resource implementation, such as Rust). Complaining about a program being written in Java because it's bloated and used too much memory isn't useful in itself, if there are no better alternatives with respect to those complaints. Pointing out the alternative forces you to think about it more critically. Saying use C++ instead of Java opens you up to thinking about the choice the developer made in using Java. Perhaps it was specifically to avoid some pitfalls in C++, or because it was perceived as easier to work in. Similarly, saying to use Java instead of Python opens you up to those same considerations. All that's really just a long way of saying, maybe the developer decided that using this system accelerated their development enough that it was worth it. It's up to the users to choose to use the program, and if they find the drawbacks of the developer's choices to be not worth it, then they can choose something else (if it exists). If nothing else exists, then maybe the reason the capability exists at this point in the first place is because of those developer choices, in which case it's hard to fault them.