Hacker News Reader

Comment by saghul | Hacker News Reader

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.

View on HN

> 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.

> 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

>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...

>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).

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.

>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.

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.

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.

> 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.

> 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).

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?

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.

Reply on news.ycombinator.com