Live data from Hacker News

Why I chose Electron.js for my side business

getloaf.io

101–110 of 127 posts

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

#101

Earlier quoted context omitted.

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.

I meant that as a nod to the person to whom you're replying, as well as the author of the article. Of course it's possible for indie developers to build native apps — but I don't begrudge them for avoiding that route, especially if their day job doesn't involve it. I am perfectly fine with criticizing giant companies for building chat apps atop Electron.

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

#102
post #92

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

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

#103

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…

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 filled with arbitrary modern HTML5 to be my "main" page/script.

I don't know why you assume that GJS is any different. Well, actually it is different: you don't have to "declare" any file. You can open up a file hello.js, write your code, and... there it is, in a dozen SLOC. (If you really wanted to, you could write an entire app in that one file.)

Not that any of this is even relevant, because you totally misread my comment. It was not about how GJS is better than Electron and the Electron folks just won't admit it. It was about how Electron is better than whatever the JS-hating GTK developers wanted, but they were too shortsighted to see the future we were going to end up in with or without their endorsement. So your kneejerk defense of your tribe is off the mark.

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

#104
post #30

Earlier quoted context omitted.

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…

The button hover and the text selection issues are one line CSS changes.

Yes, the fact this issue is literally a one line CSS change is what attracted me so strongly to using Electron.js. I'm all for software engineers building amazing macOS/Windows apps, but I wouldn't have any idea how to make text non-selectable.

In CSS it's "user-select: none;" and you're done. Playing to your strengths is important when building a business so that's exactly what I did :)

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

#105
post #68

I think React Native is also a contender, now with Windows and macOS support coming online. Yes, the "UI Framework" story still needs some work and it's obviously nowhere near the web, but otherwise it's a nice middle choice where you get a lot of the perf benefits and "native UX" look and feel, while still being able to leverage a lot of webdev skills like JavaScript and Flex.

Yes I am curious to see how it evolves

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

#106

The more I look at “modern” web sites and apps, the more I think that there should be a way to force software providers to offer discounts if their products are, essentially, bloated. (Prior to getting the software, you cannot tell how it is going to be implemented.) There is a measurable cost to me for using these “lazy” apps: - time and data plan spent downloading and updating these monsters - my disk space (yes, m…

I hadn't thought of many of these things, thanks for raising them. The flip side of not using Electron.js and going for native development (which would help solve these points) would mean I never would have shipped Loaf. That's the issue I was facing.

Due to money (development costs) and ongoing support (being able to improve and maintain the UI with CSS) I had to find a tool that would work for me.

Maybe one day with enough time and money, I'll be able to develop some beautiful native desktop apps for macOS and Windows. That would be nice :)

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

#107

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.

Plenty of people only have 2-4GB of RAM, and Slack eating up 360MB along with a couple other bloated apps and some God-foresaken autoplaying video ad can easily start requiring swapping and slow a computer to a crawl.

Sure, people could spend more money to mostly sidestep the issue (supposing they didn't have any workloads which actually benefited from all available RAM), but that doesn't make it a non-issue.

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

#108

Earlier quoted context omitted.

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 al…

Honestly though, why would you rather have that 3.4% of ram back?

Is the bottleneck in your system actually ram usage? Because I think implicit in your view is that you have a better usage for that ram. If so, what?

Because I really struggle coming up with more than about 5 electron apps I might ever run at any given time (Slack, VSCode, Discord, maaaybe Etcher..., and I'm basically out of ideas). Even then, two of those apps are both chat apps and I probably shouldn't have Discord open for work, and I don't use slack for any personal reason.

Basically - Electron apps are all applications that are UI heavy. I don't have the mental power to manage more than about 5 open and active UI apps before I'm the bottleneck, not the computer.

So at 5, you're spending 15-18% of your RAM on 5, 5! apps that you want to be interacting with rich GUIs at any given time. I just don't see it.

At least for my use cases, electron apps almost always make up a trivial amount of my total ram usage. Docker/Development Env/Vms DOMINATE in comparison.

So while I get that it could be faster, the reality of the situation is that without electron, none of the apps I listed would work on Linux at all. Instead they all do by default.

So right now on amazon, 16gb of ram is 53 bucks for a decent module. 150/16000 = .009. So basically - I paid 49 cents, and got apps that work by default on my platform of choice. That's pretty fucking amazing compared to old platform specific apps.

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

#109
post #41
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…

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.

Sciter.JS is going to change that: https://github.com/c-smile/sciter-js-sdk

I cloned a 165mb Electron app in Sciter, and it was only 6mb:

https://github.com/GirkovArpa/clipper-sciter

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

#110
post #40

Earlier quoted context omitted.

Can you please give me a list of examples I can evaluate myslef and decide if it's worth spending my time learning instead of going the Electron route?

Not the previous poster, but here is a list of cross-platform GUI libraries / toolkits: https://en.wikipedia.org/wiki/List_of_platform-independent_G...

Sciter is missing from that list for some reason.
Post reply on HN