Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I chose Electron.js for my side business

getloaf.io

Post reply on HN
Print view View original

111–120 of 127 posts

Re: Why I chose Electron.js for my side business

#111

Post by jancsika »

pwdisswordfish4 wrote: post #103
jancsika wrote: post #88

Earlier quoted context omitted.

> In fact, you can write GTK apps in JS. I'll eat my hat if it's as easy to write a hello world in GTK as it is in Electron/nw.js. Keep in mind that with Electron/nw.js I download the toolkit binary and then simply declare an arbitrary webpage or js file filled with arbitrary modern HTML5 to be my "main" page/script. That means any frontend dev can immediately get a "hello world" running with no extra tooling and imm…

Perhaps you should try a hello world GTK JS app instead of speculating about how it surely will confirm your biases. It would've taken you less time type "hello world gtk javascript" into a search engine and copy and paste the snippet into a file than writing out that bad faith argument. > Keep in mind that with Electron/nw.js I download the toolkit binary and then simply declare an arbitrary webpage or js file fille…

> there it is, in a dozen SLOC

https://developer.gnome.org/gnome-devel-demos/stable/hello-w...

The actual file is 42 lines there, which includes a shebang and a bunch of calls to GTK stuff.

And that is my point-- it's 42 lines too long to matter whether or not we travel back in time to beat back the "JS-hating GTK developers." Because as it turns out, most devs are not looking for a way to use GTK from their favorite language Javascript. They just want to continue their frontend development in a box as if they are simply developing for the web, and then have the results show up as the GUI for a cross-platform desktop application.

Re: Why I chose Electron.js for my side business

#112

Post by dangus »

MaxBarraclough wrote: post #79
_odey wrote: post #52

Earlier quoted context omitted.

I used to disagree with this view, since I was "raised" in school to think that raw performance is the only worthy attribute of a computer program, regardless of purpose. Then, when I started working on real products instead of homework I learned how wrong that way of thinking was. Of course it does not apply to everything, some apps do need every last clock cycle of speed, but so far none of mine had.

How about Electron-based chat apps like Slack and Teams? We know it's possible to implement this kind of functionality in For comparison, the Playstation 3 has 256MB of system RAM, and manages to run GTA V. [0] See the Ripcord application, discussed https://news.ycombinator.com/item?id=23163960

Ripcord itself demonstrates why Slack is written in Electron.

Is there a mobile app? Nope! Dead on arrival. In 2020, Slack or Teams or anything similar is literally useless without a mobile app.

Feature matrix says animated emojis will arrive "never." lol!

I remember the days of native chat clients like Skype and AIM. I remember how Linux and Mac platforms were basically half-clients compared to Windows. It sucked.

Electron applications like Slack and Spotify work everywhere, exactly the same. And if you think about it, that's why something like chat and music apps would prioritize ease of cross-platform deployment over perfect efficiency. They're not particularly demanding, and they are most valuable to people when they're ubiquitous. If Spotify isn't in every device I own it loses a great amount of value.

Nobody's sitting at their Activity Monitor staring at the RAM usage of Slack or Teams. In reality, performance is fine. It's just chat.

(Interestingly enough, I've never found a music application that skips tracks more quickly than Spotify, even for locally-stored music. It's just instant with no gaps.)

Re: Why I chose Electron.js for my side business

#113

Post by dangus »

Falling3 wrote: post #84
MaxBarraclough wrote: post #79

Earlier quoted context omitted.

How about Electron-based chat apps like Slack and Teams? We know it's possible to implement this kind of functionality in For comparison, the Playstation 3 has 256MB of system RAM, and manages to run GTA V. [0] See the Ripcord application, discussed https://news.ycombinator.com/item?id=23163960

Yea, completely agree. I think context is very important here. We should not be making the same arguments for a one-person side business and a company with 400MM in revenue. Slack really can't stand on the arguments presented in the article.

Slack didn't exactly start with 400MM of revenue.

Re: Why I chose Electron.js for my side business

#114

Post by xg15 »

_odey wrote: post #52
jsdavid wrote: post #41

Earlier quoted context omitted.

The tweet mentioned in the article, saying: Electron app memory usage: 150MB Native app memory usage: 0 MB (because you never ship it) really hit home for me.

I used to disagree with this view, since I was "raised" in school to think that raw performance is the only worthy attribute of a computer program, regardless of purpose. Then, when I started working on real products instead of homework I learned how wrong that way of thinking was. Of course it does not apply to everything, some apps do need every last clock cycle of speed, but so far none of mine had.

In general, I think you're right - but that mindset can quickly become one of shifting costs to others: E.g., $framework-of-your-choice may increase your velocity and allow you to ship faster.

However, it might also make it harder to find bugs and it will produce bloat with real, noticeable consequences - e.g. increased RAM, CPU and disk usage, more sluggish UI behavior, etc - except, those effects will happen on the user's machine, not the developer's, so a developer might be tempted to ignore them.

Re: Why I chose Electron.js for my side business

#115

Post by xg15 »

dangus wrote: post #112
MaxBarraclough wrote: post #79

Earlier quoted context omitted.

How about Electron-based chat apps like Slack and Teams? We know it's possible to implement this kind of functionality in For comparison, the Playstation 3 has 256MB of system RAM, and manages to run GTA V. [0] See the Ripcord application, discussed https://news.ycombinator.com/item?id=23163960

Ripcord itself demonstrates why Slack is written in Electron. Is there a mobile app? Nope! Dead on arrival. In 2020, Slack or Teams or anything similar is literally useless without a mobile app. Feature matrix says animated emojis will arrive "never." lol! I remember the days of native chat clients like Skype and AIM. I remember how Linux and Mac platforms were basically half-clients compared to Windows. It sucked. E…

> Electron applications like Slack and Spotify work everywhere, exactly the same.

Yes, because they're just web pages. Then why not just use the browser to display them?

Re: Why I chose Electron.js for my side business

#116

Post by xg15 »

To add some criticism from a user's perspective: I hate electron apps as a user. Not because of the bloat - it's annoying but doesn't cause problems in practice - but because of the UX. native GUIs all have some visual consistency and design rules and metaphors you can orient yourself by.

Browser-based apps have no common UI rules at all, which makes them significantly more confusing to use.

Re: Why I chose Electron.js for my side business

#117

Post by tumult »

Cu3PO42 wrote: post #65
OJFord wrote: post #48

Earlier quoted context omitted.

> People love Discord. On a desktop they have no choice but to use its Electron client These are just the last few results for `yay -Ss discord`: aur/purple-discord-git v0.0.r637.d47f0bc-1 (+13 0.24) A libpurple/Pidgin plugin for Discord. aur/ripcord 0.4.27-1 (+20 0.66) Qt-based Discord and Slack client aur/discord-canary 0.0.115-1 (+29 2.70) All-in-one voice and text chat for gamers that's free and secure. aur/disco…

The ToS explicitly forbid usage of third-party clients and people have been banned over this issue. Some people may be fine with taking this risk, but I also absolutely understand not wanting to deal with it. Personally, I fall in the latter category, so I mostly have the web client open in a pinned tab.

Can you show where in the ToS it says third-party clients are forbidden? (It doesn't)

Re: Why I chose Electron.js for my side business

#118

Post by piaste »

MaxBarraclough wrote: post #102
_odey wrote: post #92

Earlier quoted context omitted.

I don't use the Slack app, there is no need to do that when I can have it running in a browser tab instead. Not sure what Teams is either...

The Slack app is essentially a Chromium browser running the usual web-based Slack. It uses the same amount of resources running in a tab in your browser. I think there are some UI niceties to the 'app' version but it's essentially the same. Teams refers to Microsoft's competing product. Like Slack, its desktop app is really just the web version.

> The Slack app is essentially a Chromium browser running the usual web-based Slack. It uses the same amount of resources running in a tab in your browser.

I would expect that a pinned Slack tab in Chrome/Edge would be able to share some resources with the browser that a separate Slack app can't.

Has anybody tested the performance difference between running 100 browser tabs vs. running the same webapps as 100 electron processes?

Re: Why I chose Electron.js for my side business

#119

Post by jcelerier »

joshmanders wrote: post #66
jcelerier wrote: post #55

Earlier quoted context omitted.

> Without Electron it would take me months of intense dedicated time, which I would rather spend on something else. c'mon, getting the very basics of it in Qt took the better part of 15 minutes and less than 100loc - then it's mostly a menial "where to show which data" https://github.com/jcelerier/fio-ui

> c'mon, getting the very basics of it in Qt took the better part of 15 minutes and less than 100loc I used to think this same way about things because I had so much time in the tools that I never looked at stuff from a perspective of people who have no clue. Now that I have a friend going through coding schools and everything with zero understanding, everything I think is "just a 15 minutes of tinkering and you'll k…

But OP isn't a newbie going to coding school, he/she already knows JavaScript and webdev in general ! Of course if you don't know programming at all it's harder (even then, 3 months seems like an awful lot - this year I teach programming to graphic design students and in ~15 hours they are already able to do neat things on their own with p5.js).

To give my own experience, I'm almost exclusively a C++ coder but had to do two Web projects earlier this year, a React one and a custom one, and even though both times it felt like eating nails, it didn't take more than a day to "get in" ; I'm confident that it's be the same no matter the language except maybe APL and derivatives :)

Re: Why I chose Electron.js for my side business

#120

Post by [deleted] »

jancsika wrote: post #88
pwdisswordfish4 wrote: post #74

Earlier quoted context omitted.

> I would never attempt to implement something like this in Qt or GTK In fact, you can write GTK apps in JS. A year or two before Electron came along, the Gnome folks had the foresight to declare that JS would be the language of choice for promoting GTK and Gnome app development, with the option to drop back to C otherwise. This caused a minor controversy, where the community decided to rage against this effort and e…

> In fact, you can write GTK apps in JS. I'll eat my hat if it's as easy to write a hello world in GTK as it is in Electron/nw.js. Keep in mind that with Electron/nw.js I download the toolkit binary and then simply declare an arbitrary webpage or js file filled with arbitrary modern HTML5 to be my "main" page/script. That means any frontend dev can immediately get a "hello world" running with no extra tooling and imm…

[deleted]
Post reply on HN