5 ms·

I don't understand much of the criticism in this thread so far. Yes, the app is built using web technologies and uses Electron, but AFAIS it's a fully fledged

by saghul 10y ago

I don't understand much of the criticism in this thread so far. Yes, the app is built using web technologies and uses Electron, but AFAIS it's a fully fledged client, not just a wrapper around a website. The interface is built right there with CoffeeScript and LESS, and there is a Hangouts JS library which they use. I'm not a big fan of using HTML/JS/CSS for everything myself, but this project looks really complete and well built. If it was built with C++ and Qt someone would come and say "why didn't you use Gtk? or <framework X>?". Keep up the good work.

Lazare 10y ago
> Yes, the app is built using web technologies and uses Electron Right. It's a chromium window wrapped around some HTML and JS, aka a website. > AFAIS it's a fully fledged client, not just a wrapper around a website. Nope, just a wrapper. True, it's a local webpage served on your desktop they wrote themselves, but it still has all the disadvantages that you incur when your client is just a web page in a browser. > If it was built with C++ and Qt someone would come and say "why didn't you use Gtk? Electron has enormous drawbacks which C++ and Qt do not have.
- RubyPinch 10y ago
  > 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.
- taneq 10y ago
  > Right. It's a chromium window wrapped around some HTML and JS, aka a website. So 'a website', to you, is anything using HTML and JS? Because a local HTML+JS app removed what is, to me, the second biggest weakness of "the cloud", namely the dependence on an internet connection and some third party server. OK, OK, this is a chat server so it won't work without a connection anyway but you get my point.
  - kbenson 10y ago
    > OK, OK, this is a chat server so it won't work without a connection anyway but you get my point. That doesn't matter. It still can act like a native application (because it is a native application). All code is sourced and run locally, and doesn't require you to interface with it though a separate program (as that's bundled right in with it). If that's not native, neither is an application written in Perl or Python (they run through an interpreter), or Java for that matter (it's run through the JVM).
- dubcanada 10y ago
  What happens if you built a Qt app and used Qt Web Engine for the entire app, would you complain? Do you complain about Steam, GOG, or one of the other 1000 apps that use Qt or what ever GUI kit and then just use an embedded browser for 90% of the app?
  - monksy 10y ago
    I wouldn't as long as it was just the chat window and was used for formatting. Native apps generally perform better, tend to be lighter. (The slack client takes up 400mb in 8 processes.. it's basically a web app within a containing application) Steam uses a web widget for the store, but the entirety of Steam isn't built in HTML/JS. It makes sense to do it that way. If steam was entirely written in a web language you would never have the platform support that you currently have, the ability to download at the speeds that you currently have, etc.

by saghul 10y ago

Lazare 10y ago

> Yes, the app is built using web technologies and uses Electron Right. It's a chromium window wrapped around some HTML and JS, aka a website. > AFAIS it's a fully fledged client, not just a wrapper around a website. Nope, just a wrapper. True, it's a local webpage served on your desktop they wrote themselves, but it still has all the disadvantages that you incur when your client is just a web page in a browser. > If it was built with C++ and Qt someone would come and say "why didn't you use Gtk? Electron has enormous drawbacks which C++ and Qt do not have.

RubyPinch 10y ago
> 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.
taneq 10y ago
> Right. It's a chromium window wrapped around some HTML and JS, aka a website. So 'a website', to you, is anything using HTML and JS? Because a local HTML+JS app removed what is, to me, the second biggest weakness of "the cloud", namely the dependence on an internet connection and some third party server. OK, OK, this is a chat server so it won't work without a connection anyway but you get my point.
- kbenson 10y ago
  > OK, OK, this is a chat server so it won't work without a connection anyway but you get my point. That doesn't matter. It still can act like a native application (because it is a native application). All code is sourced and run locally, and doesn't require you to interface with it though a separate program (as that's bundled right in with it). If that's not native, neither is an application written in Perl or Python (they run through an interpreter), or Java for that matter (it's run through the JVM).
dubcanada 10y ago
What happens if you built a Qt app and used Qt Web Engine for the entire app, would you complain? Do you complain about Steam, GOG, or one of the other 1000 apps that use Qt or what ever GUI kit and then just use an embedded browser for 90% of the app?
- monksy 10y ago
  I wouldn't as long as it was just the chat window and was used for formatting. Native apps generally perform better, tend to be lighter. (The slack client takes up 400mb in 8 processes.. it's basically a web app within a containing application) Steam uses a web widget for the store, but the entirety of Steam isn't built in HTML/JS. It makes sense to do it that way. If steam was entirely written in a web language you would never have the platform support that you currently have, the ability to download at the speeds that you currently have, etc.