Live data from Hacker News

Why I chose Electron.js for my side business

getloaf.io

91–100 of 127 posts

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

#91
post #65
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.

Oh fair enough, I didn't know. (As you can see from my listing, I'm using the official one. But just because 'meh, whatever, it's ok, I don't care' rather than because I didn't like the others or knew about the terms prohibiting it.)

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

#92
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

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

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

#93
post #30

I understand performance concerns, but not "native" app. Most popular thing on desktop used by people are Facebook, Youtube, Instagram, Gmail and Google Calendar, Reddit, Netflix, Wikipedia. I have never seen people avoiding them, because they don't have a native interface. As long as interface is intutive, people are happy to use them.

I’m working on some Windows apps currently in the native-ish WPF and UWP frameworks. Being somewhat detail-oriented, I’ve noticed a few major areas where Electron apps tend to deviate from native: * button/link handling: win desktop uses the pointer with hover effects; electron uses a hand cursor with hover effects * minimize/maximize/close buttons, and title bars in general; electron apps tend to have them being big…

Hopefully WinUI3 will help with a lot of Windows native UI toolkits' shortcomings. I haven't looked much into it myself though.

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

#94
post #44
post #39

Earlier quoted context omitted.

You keep mentioning Wayland as if it is the magic keyword that will strike fear into the heart of native app developers. That's just not a thing, it won't matter at all for your app. The irony is that if you write a desktop app at one point, you will soon learn about all the things that Chromium doesn't do for you. Want to run some kind of privileged operation (since disk benchmarks came up)? Tough luck, there is no…

I mention it because that's basically what I keep reading related to it, the fact that it's incompletely implemented right now and some apps that used to work with X no longer do. Isn't it natural to consider it a potential risk for app development as well? For the OS specific stuff that chromium doesen't handle, that's fair, hopefully I'll have to deal with as little of that as possible.

[deleted]

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

#95
post #6

No matter how much I hate the bloat, and no matter how much I don't like JavaScript as and language due to it's behaviour around type coercion, I can't help it but to agree with everything in this article. Reusing the frontend skills I learned throughout the years to build desktop apps when needed, instead of having to learn an OS toolkit (and in the case of linux, multiple desktop environments, neve mind Wayland vs…

People like to complain about JS but the fact is that it's been completely optional on the frontend to write in it for 8-10 years, certainly the whole time Electron has been around. JS is a fine compile target though.

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

#97
The pervasiveness of Electron without its flaws is why I'm really excited for Flutter desktop. It really does feel like write once, run everywhere. It is much faster and has minimal RAM usage because its compiled to a native binary, plus I get mobile and web apps out of it too.

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

#98

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

The PS5 has 16GB of RAM. So does the Mac I'm using. Slack is taking less than 1% of my Ram. PS3 was released 13 YEARS ago. At the time AIM was the dominant chat client, and it probably took more like 5% of RAM available.

> PS3 was released 13 YEARS ago.

That's why I used it for my example. Past systems are a useful benchmark for what it's practical to do with a certain level of computational horsepower.

> Slack is taking less than 1% of my Ram.

My system has 8GB, so 3.7%. I'd rather have 3.4% of my memory back.

More broadly, we should consider that we may run many bloated apps. Even if Slack doesn't do too much harm on its own, if all your desktop apps are using 10x the resources they could be using, it adds up to you spending more on hardware than you should have to.

You paid for that 16GB of RAM. That should let you do a lot more than old computers can, rather than doing the same things we did 15 years ago with bloated software.

> At the time AIM was the dominant chat client, and it probably took more like 5% of RAM available.

Right, like Ripcord, it did roughly the same thing Slack/Teams do, using far fewer resources.

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

#99

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

I think we can hold multi-billion dollar venture-backed companies to a different standard than we do indie developers working on side projects.

Not sure if you meant that as a nod to Ripcord.

Slack has, to put it mildly, plenty of money, and gave us a 300MB bloated client. Ripcord is a payware alternative client made by a single developer.

Things seem to be precisely backward.

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

#100
post #13

For me the big win is that it feels familiar to users. It's not a native app, but it looks like their native browser. Users are acutely sensitive to apps that feel right. It's something Java learned the hard way, or not at all: there's an uncanny valley if you get it wrong, and users hate that. Native apps will always be better than a web app, but a web app will be better than an app that doesn't really have a home o…

This is how I feel about Flutter today. Seems like a cool paradigm on the face of it, but they never feel native nor do they feel like a WebView or what-have-you. They're in their own uncanny valley.
Post reply on HN