Yakyak: Electron Chat Client for Google Hangouts(github.com)
github.com
Yakyak: Electron Chat Client for Google Hangouts
https://github.com/yakyak/yakyak
84 comments
For those of you that use Pidgin, there's also a really great libpurple plugin that I've been using: https://bitbucket.org/EionRobb/purple-hangouts/
It works really well, but it doesn't have history scrollback. I'm happy when I don't have to open up my browser to chat with people.
It works really well, but it doesn't have history scrollback
That caused so many arguments between me and a former girlfriend.
That caused so many arguments between me and a former girlfriend.
>> but it doesn't have history scrollback
That's because it's not hangouts, it's gchat.
That's because it's not hangouts, it's gchat.
From the perspective of the author. This is fantastic work. Keep up the enthusiasm, and I hope to see more from you.
From the perspective of google, they should have done this 3 years ago. The chrome hangouts plugin is an atrocity. But at this point I've already fully abandoned google hangouts except for video chats at work. Too little, too late.
From the perspective of google, they should have done this 3 years ago. The chrome hangouts plugin is an atrocity. But at this point I've already fully abandoned google hangouts except for video chats at work. Too little, too late.
Strongly agree. I discovered YakYak a couple weeks ago and haven't looked back at the plugin or native apps. For those curious why people may not like the alternatives:
Chrome Plugins/Apps:
- Cmd-tab doesn't work properly with apps. It will bring up my browser window instead.
- My browser has to be open. Chrome has a large battery impact even when just sitting there. I often completely close Chrome when roaming. YakYak barely even registers
Pidgin/Adium:
- You don't see missed messages from when you weren't logged in. I used to get in lots of fights with my girlfriend because of missed messages.
- Can't paste images/screenshots from the clipboard. Maybe Pidgin supported this? Adium doesn't.
- History isn't shared between multiple computers (chat history on home PC isn't available on work PC)
YakYak solves all of those problems for me. I am thrilled YakYak exists. Huge thanks to the author.
Chrome Plugins/Apps:
- Cmd-tab doesn't work properly with apps. It will bring up my browser window instead.
- My browser has to be open. Chrome has a large battery impact even when just sitting there. I often completely close Chrome when roaming. YakYak barely even registers
Pidgin/Adium:
- You don't see missed messages from when you weren't logged in. I used to get in lots of fights with my girlfriend because of missed messages.
- Can't paste images/screenshots from the clipboard. Maybe Pidgin supported this? Adium doesn't.
- History isn't shared between multiple computers (chat history on home PC isn't available on work PC)
YakYak solves all of those problems for me. I am thrilled YakYak exists. Huge thanks to the author.
If you prefer pidgin/adium: https://bitbucket.org/EionRobb/purple-hangouts
Basically implements full hangouts into pidgin (connects to hangouts over "hangups" protocol rather than xmpp).
It still has some minor issues. from finch (ncurses pidgin) for example, it makes links that send people to a blank page with some hangouts.google.com/ proxy stuff going on that never gets followed. it also has weird issues with instantly marking some conversations as read. Otherwise I've been viewing it as an inplace upgrade for using xmpp on pidgin.
Basically implements full hangouts into pidgin (connects to hangouts over "hangups" protocol rather than xmpp).
It still has some minor issues. from finch (ncurses pidgin) for example, it makes links that send people to a blank page with some hangouts.google.com/ proxy stuff going on that never gets followed. it also has weird issues with instantly marking some conversations as read. Otherwise I've been viewing it as an inplace upgrade for using xmpp on pidgin.
No Mac support? or is it just not documented?
There was a comment on the bitbucket a long while ago about "how to build for adium" but i no longer see that. :(
Adium is the pidgin for Mac.
For me, one of the biggest draws over the official client are that it opens links in my OS default browser, not just Chrome. They used to do this, but have made changes so that links only open in Chrome. There's a smattering of threads on this issue with no response from Google or the Hangouts team.
> Cmd-tab doesn't work properly with apps. It will bring up my browser window instead
try Cmd-`
try Cmd-`
That only works if I already have Chrome in the foreground. If I cmd-tab to another app to copy something, and then cmd-tab back to the Hangouts Chrome App to paste it but it actually just shows me my browser window instead. There is no way to swap back and forth between the Hangouts Chrome App like every other app even though it has a dedicated Dock icon.
The name of this project reminded me a silly Ukrainian joke:
— ... ("have you been in the zoo?") — ... ("yes, I saw a yak!") — І як як? ("so how was the yak?") — Як як як. ("Like a yak")
— ... ("have you been in the zoo?") — ... ("yes, I saw a yak!") — І як як? ("so how was the yak?") — Як як як. ("Like a yak")
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.
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.
> 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.
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.
> 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
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
>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...
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...
>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).
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).
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.
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.
>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.
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.
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.
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.
The latest YakYak release is only 50MB. YakYak has been running on my Mac the entire day now and it is only consuming 55MB of RAM.
I tend to agree that Electron apps are heavy but it seems like there are ways to make it small like this one.
I tend to agree that Electron apps are heavy but it seems like there are ways to make it small like this one.
> 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.
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.
> 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).
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).
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?
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?
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.
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.
Like many "desktop" current apps it opens another browser that only loads one page: the "desktop" app.
It uses electron (http://electron.atom.io/) which uses nodejs+chromium.
It uses electron (http://electron.atom.io/) which uses nodejs+chromium.
I am happy to see a more webapps break out of the browser. That way the apps make better use of the features of the OS.
Be aware that this is not the case of an app "breaking out of the browser":
BrowserWindow = require('electron').BrowserWindow
.
.
.
mainWindow = new BrowserWindow {
width: 730
height: 590
icon: path.join __dirname, 'icons', 'icon.png'
show: true
titleBarStyle: 'hidden-inset' if process.platform is 'darwin'
}
I would've assumed that code was implied by the whole 'It uses Electron' thing in your first comment. And it is breaking out of the browser seeing as you don't need to open a browser and type in a URL to view it.
I'm not sure if I can understand if your comment is a complaint or not.
It is just a remark.
Although i do prefer to reuse the current running browser.
Although i do prefer to reuse the current running browser.
Your comment read as if you meant the app was just a wrapper around a web app. It's not, although that doesn't make much of a difference.
Somehow I still can't consider a webapp in a window a 'desktop app'. I'm still waiting for QHangups to migrate to QWebEngine. (http://github.com/xmikos/qhangups)
There is also a Chrome extension for hangouts, and it can even run when Chrome isn't visible (authored by Google). Perhaps most useful is the "transparent ui" mode, where you have floating heads - see the second screenshot at http://www.omgchrome.com/google-hangouts-chrome-app-update/ - although for a change that is available on Windows and Linux, but not Mac! (The page also has a link to the Chrome extension.)
You mean there's a Chrome App in addition to the Chrome Extension.
The problem with the Chrome App is that you still need to have Chrome running which on OS X means the Chrome dock icon, and any other downsides of having a running Chrome process (e.g. battery life impact).
The problem with the Chrome App is that you still need to have Chrome running which on OS X means the Chrome dock icon, and any other downsides of having a running Chrome process (e.g. battery life impact).
The Windows build doesn't appear to work at all. In addition to getting file path too long issues, once I've accommodated the app by extracting on the root of my drive it never loads past a white screen.
I have been using an app named Franz @ http://meetfranz.com/.
Its multi-protocol and based on Electron. Not opensource from what I know.
Its multi-protocol and based on Electron. Not opensource from what I know.
Franz unfortunately frames the hangouts.google.com interface which has terrible bugs when multiple people are chatting with you at the same time. If you're typing in a chat window and someone else messages you, it pops over your current chat window and the last half of your sentence types in the new window. If you switch back it'll pop back over every single time the other person messages you.
As a sop to those who don't consider Electron apps desktop apps, we s/Desktop/Electron/'d the title. Please let's discuss this app now.
Why would I use this over say Adium or similar multi-protocol app?
See my comments here: https://news.ycombinator.com/item?id=11925103
At first, I assumed that this had something to do with http://www.yakyak.org/
I assumed https://www.yikyak.com/, which is a local chat app (you see messages posted from people nearby). The name sounds very similar, I'd be worried about infringing Yik Yak's trademark.
Other than a green bar with a white box on the left side and a grey box to the right side what am I supposed to be seeing here?
Really glad to see this. Any plans on implementing voice dialing/receiving (Google Voice)?
[deleted]
i don't know much about Hangouts -- am i connecting with/using Hangouts when i am using Gmail's chat feature?
I'm kind of tired of the criticism on every post about an up built on electron. I mean, we all know the disadvantages it has with respect to native gtk or qt, but we also must remember the advantages it brings to developers to write multiplatform and VERY (not highest) performance apps in an easier way.
Like it or not it is the era of websites. For people like me who always preferred desktop apps, this is good news because many website-like apps are ported in a "almost native way". Anyway, web technology like html+js+css is not that bad and it's evolving and improving fast as front-end.
I've never heard someone call electron apps 'very performant'. If anything, they're "kinda performant". Even "sorta". In fact, that's the biggest complaint, that the performance flat out sucks.
For me the biggest problem with web apps in a browser are keyboard shortcuts. E.g.: does Cmd+P print the webpage or the contents of the edited document? Electron applications solve this problem. In the end it is important to stuff the stuff requiring performance into a native module and you are set. Having worked with JNI I prefer writing Node plugins and writing interfaces in HTML5 is great compared to stuff like Gtk (and even Qt)
An author can use print stylesheets to make cmd-P work as expected. Try it out in google docs for example.
Yes. But the shortcuts are not consistent between different web-applications. Inconsistency is he death for muscle memory. Also simple copying and pasting is not always doing what I think (e.g.: in Google docs) (it is partly my fault as I prefer safari and they did not have yet implemented all of the necessary APIs to make it work). Another advantage of Electron apps is that they do not have a concept of back and forward by default. There is no losing work in a text editor because one has unfocused the text field and pressed backspace
I wouldn't consider web apps "almost native" until they take up the UI paradigms and hopefully the UI design (or at least the spirit of it) of the host OS. There's nothing native about an application that doesn't look or act like it belongs on any particular platform.
Does that mean Sublime is not native, because it doesn't use the OS's theme or widgets?
Sublime still qualifies as native. It doesn't use native theming, but the UI widgets are in fact native (just heavily skinned). This is what allows it to have extremely low latency text input (compared to Atom/Brackets/VS Code) and under OS X, allows it to automatically adopt the extensive set of standard text editing shortcuts the OS implements.
I wonder if the same people would say that Atom or Visual Studio Code is a "web app."
agreed - but GTK2 is what makes the experience extra horrible when using on desktops like GNOME.
I ended up making an electron gtk3 build script for the few apps I prefer to use that choose to go the electron route: https://github.com/nikolowry/electron-gtk3
I ended up making an electron gtk3 build script for the few apps I prefer to use that choose to go the electron route: https://github.com/nikolowry/electron-gtk3
I am sick and tired of these wrappers falsely branded as "desktop apps". This is not a desktop app, i.e. not a native client. It's an embedded browser that comes with even more negatives than a Chrome app/panel!
Now, when we have libui-node [0], which is a Node.js wrapper around libui [1], developers, you have no excuses!
[0]: https://www.npmjs.com/package/libui-node
[1]: https://github.com/andlabs/libui
Now, when we have libui-node [0], which is a Node.js wrapper around libui [1], developers, you have no excuses!
[0]: https://www.npmjs.com/package/libui-node
[1]: https://github.com/andlabs/libui
> you have no excuses!
> It is in early stage of development
> OSX should work too, but it's not tested.
> Windows has yet to be configured in build scripts, but it will be supported in further releases.
> There are very few tests developed
> This is not yet battle-tested in a real app
All that from the official Readme [0] and you're saying there's no reason not to use it?
[0] https://github.com/parro-it/libui-node
> It is in early stage of development
> OSX should work too, but it's not tested.
> Windows has yet to be configured in build scripts, but it will be supported in further releases.
> There are very few tests developed
> This is not yet battle-tested in a real app
All that from the official Readme [0] and you're saying there's no reason not to use it?
[0] https://github.com/parro-it/libui-node
This is just one of the wrappers around libui [0], which itself works fine, and is tested on all platforms. Well, it's in alpha stage, true, but so what - wait until it's stable, and then start building?
[0]: https://github.com/andlabs/libui
[0]: https://github.com/andlabs/libui
You're criticizing a released project for their technology choice, advocating that they should have waited to build it until some other tech was ready... Maybe take a step back and just appreciate that they built and shipped something. If you hate Electron, move on and don't use it.
Did you care to read? I meant they should not wait.
Electron uses gigabytes of RAM - it's the one reason I switched to weechat from Slack's "desktop" client!
Such "desktop" apps are a disgrace and they run way more efficiently in the browser compared to having multiple copies of browsers running in parallel.
Electron uses gigabytes of RAM - it's the one reason I switched to weechat from Slack's "desktop" client!
Such "desktop" apps are a disgrace and they run way more efficiently in the browser compared to having multiple copies of browsers running in parallel.
Slack is currently using 144 MB on my Windows machine (with a lot of public channels and DMs active). Electron may give up some performance for a lower development effort, but that's the known trade-off. I think you're making it sound a little more bleak than it actually is, current performance of Electron apps is pretty good (if designed properly).
Send me a screenshot and make sure it includes virtual memory as well. I've never had any embeded browser app to use less than a GB of overall memory (in most cases, Slack uses well over 2GB).
Funny how these Open Source projects affect some people, there are other options out there. Most likely you didn't even try it.
I love to see JS haters going crazy every time an open source electron project has some popularity.
Please don't make the thread worse by posting snarky disses of disses. It just stirs up acrimony and adds no information, regardless of whether your point is right.
The information added is the fact that it's frequent here to see disses just because an upvoted post refers a JavaScript/Electron project. That's useful information for newcomers to the forum.
Looks great. However, I wonder why Hangouts specifically? Am I just alien to a world where people actually use hangouts? I really really don't like it myself. Not that that is reason enough to assume all other people don't like it as well, obviously. How do people use it and why would you 'give' Google all your private chat conversations?
Let's talk about the alternatives to Hangouts:
Google's Android app has much better performance than Facebook's. (Particularly in terms of battery life. Not sure about iOS.)
IRC and XMPP are both a pain to set up. (I would love to be wrong about this. I'd run my own server if if you can find me dead-simple clients for enough platforms.)
SMS and MMS work well for phones but not for PCs.
AIM, MSN, and Yahoo, last I checked, work well for PCs but not phones. (Not sure if they still work well for PCs, pretty sure they haven't started working well for phones.)
Google's Android app has much better performance than Facebook's. (Particularly in terms of battery life. Not sure about iOS.)
IRC and XMPP are both a pain to set up. (I would love to be wrong about this. I'd run my own server if if you can find me dead-simple clients for enough platforms.)
SMS and MMS work well for phones but not for PCs.
AIM, MSN, and Yahoo, last I checked, work well for PCs but not phones. (Not sure if they still work well for PCs, pretty sure they haven't started working well for phones.)
There are many XMPP free servers, and some clients are awesome. Like conversations.im.
Setting up a server is not terribly difficult though. I bet there are some simple container solutions.
Setting up a server is not terribly difficult though. I bet there are some simple container solutions.
It still requires you to setup an XMPP server and proper DNS for federation.
With hangouts, if someone has a google account, there isn't much else to setup which makes things much easier for non-technical friends & family.
Hangouts has other benefits:
- All users support the same call/video features
- Using GCM means that battery life is better than with long polling, in my experience
- Integration with Google Voice means you can add phone users to your video call
- Sending images is built in
- Single chat history that's synchronized[1]
- Works on Linux, Windows, macOS, Android and IOS with the standard clients[2]
I've setup an XMPP server before and it wasn't that hard. I have friends/family using Hangouts and Signal messenger. Hangouts provides a pretty smooth experience and is my generally preferred way to initiate a video call with my family who runs a variety of platforms (Andriod, iOS, Windows, macOS, etc)
[1] Of course this is possible because of Google being the hub with is the grandparent's concern
[2] XMPP also has this but some chat solutions are not as widely available. Of course the web app will work anywhere you can run a modern browser. I'm thinking of the official Chrome extension and I don't know if it works in BSD or other OS's.
With hangouts, if someone has a google account, there isn't much else to setup which makes things much easier for non-technical friends & family.
Hangouts has other benefits:
- All users support the same call/video features
- Using GCM means that battery life is better than with long polling, in my experience
- Integration with Google Voice means you can add phone users to your video call
- Sending images is built in
- Single chat history that's synchronized[1]
- Works on Linux, Windows, macOS, Android and IOS with the standard clients[2]
I've setup an XMPP server before and it wasn't that hard. I have friends/family using Hangouts and Signal messenger. Hangouts provides a pretty smooth experience and is my generally preferred way to initiate a video call with my family who runs a variety of platforms (Andriod, iOS, Windows, macOS, etc)
[1] Of course this is possible because of Google being the hub with is the grandparent's concern
[2] XMPP also has this but some chat solutions are not as widely available. Of course the web app will work anywhere you can run a modern browser. I'm thinking of the official Chrome extension and I don't know if it works in BSD or other OS's.
conversations.im requires either entering your credit card into Google Play, or installing from F-Droid. That's already too much.
I'll set up the server, I'll put time and money into it, but it needs to be a one-step process to add each of my friends or it won't work.
I'll set up the server, I'll put time and money into it, but it needs to be a one-step process to add each of my friends or it won't work.
The telegram desktop app works really well
Mumble is easy to set up and you can run a server on your WRT router, droplet etc. to share with others.
I mostly use Skype
Skype is pretty terrible software both in term of UX, resource usage and the political implications we all know about
Versus Hangouts? Skype and Hangouts seem to be on equal footing for UX issues and resource usage in my estimation. As for the "political implications", Google is also a big American company that has to play nice when one of America's three letter agencies knocks on the door, it's the exact same political implications and you are lying to yourself if you believe otherwise.
All of my friends, family and co-workers use Hangouts. It's the only messenger I'm using.
We use group hangout chat at work all the time. Considering Google is not even top 5 in chat market, I don't know why are you even worried about Google when Facebook has more private chat information than any other company.