Hacker News Reader

Comment by ilrwbwrkhv | Hacker News Reader

Every single app that I use, I try and make sure it is native. I shun electron apps at all cost. It's because people who put in effort to use the native APIs put in a lot more effort in the app in general based on my anecdotal evidence. It is also more performant and smaller in size, things that I cherish. It also pays homage to limits and striving to come up with new ways of overcoming them, which hackers would have to do in the past. I don't think not worrying about memory, CPU, etc are not healthy in the long run. Slack desktop app is almost 1 gig in size. That is crazy to me, no matter the "memory is cheap" mantra.

View on HN

Agreed. If you have a CPU from 2012 onwards, 16GB of RAM and an SSD, that’s a respectable hardware setup. It might not be the fastest piece of kit on the planet, but I don’t see any reason why it couldn’t last another 3 to 5 years without feeling slow.

Electron apps invariably make such kit feel slower than it actually is. You can get good performance out of even older hardware if you treat it well and load it with good software that respects the hardware.

I type this from a 2014 MacBook Air with 8GB of ram, still going strong, no upgrades except a battery replacement. Everything is still as snappy as the first day I got it.

No electron apps!

Yep, the new Steam library being a bloated web app is what forced me to install more RAM. I normally don't close out of applications when I'm not using them, so I was always hovering around ~6-7 of my 8 gigs of RAM in use. Then they update the library to the new bloated version, and my computer starts freezing because the library memory footprint is so much larger that my computer was having to use over a gig of swap space.

I have a rig powerful enough to run a lot of last-gen games at 4K with high quality settings, and a lot of current-gen ones at mid to high settings and 1080p. The fucking redesigned Steam library lags, none of the animations (why does it need animations?!) are even close to smooth, and there's massive delay on every input. I've never once encountered a move toward webtech, or toward heavier and "appier" JS use in something that's already webtech, and gone "oh good, this works much better now, I'm so glad they did that."

And somehow it's still dramatically better than the Epic Games launcher.

I don't know what these companies are doing. Clearly they're not paying attention though. This is not merely low-hanging fruit that's going ignored, it's watermelons.

>I normally don't close out of applications when I'm not using them, so I was always hovering around ~6-7 of my 8 gigs of RAM in use.

That sounds like your problem. And I refuse to believe that the new steam UI uses 2gb of memory.

The "<resource> is cheap" mantra also really only makes sense if you are writing server code, where you yourself pay for all the memory your code will ever use. If you deploy code to a large number of users it makes little sense. If a million users start your app daily, and your app has a 5 second load time and uses 300mb of ram, you are wasting over 50 days of user time, and hogging close to 300 terabytes of ram.

So you are telling me that I can easily exchange development time which I would have to pay for end-user resources, which I would not have to pay? Sounds like a great deal.

In a fair society it should be taxed as an externality. There is a real environmental cost associated with software bloat.

People pay with electricity, uncomfortable temperature and fan noise, wasting time working on slow apps.

Apparently, they trade off still worth it, as many electron apps are popular despite these issues. Many times there is electron app or nothing.

Your last sentence hits the nail - many users don't have a choice in selecting the application, and due to industry fads can't expect to have a better option.

I can make a great chat system that uses fast native client, but it won't change the fact that Corporation A paid for a slack license and won't switch to mine.

Then I hope we would also tax the bad UX of the competing 20-year old Frankenstein applications, which lead to slower business processes (= more resources used as well).

In a fair society closed software would be illegal and people wouldn’t tolerate this kind of stupidity.

No need to hack it with taxes.

> In a fair society closed software would be illegal

What?

But, I am traiding my time for my user's CPU and RAM, and evidence suggests many users are willing to pay the CPU and RAM to get more apps with more features.

Waste the company does not have to pay for is not waste as far as they are concerned. Customers rarely notice that kind of waste either, or at least not enough to do anything about it.

People also takes it a bit to far. Sure, RAM is cheap enough, but if your application requires 64GB of memory you may start having other issues.

We have customers who requires servers with 64GB+ memory, of single applications. This is running on VMs in VMWare. If a ESXi host crashes, you'd want VMWare to migrate your VM to another ESXi host, but that becomes somewhat tricky if you need to locate one with 64GB of available memory. Unless of cause you're way over-provisioned, which is actually pretty expensive. More realistically VMWare will start moving a ton of VMs around to put all those with little memory usage on other hosts, in an attempt to find 64GB for your VM. This takes time.

It can be difficult to explain to people that really this should look at their memory consumption, if nothing else to plan for fail-over.

It is true that there is a a correlation between lower level programming and better programming in general. You probably won't see someone writing asm but creating crazy O^2 algorithms that run on every frame with memory allocations that run in the inner loop.

At the same time a native win32 program can pack significant functionality into a 20KB exe. Put these together and you have a program where everything is instant, all the time on any computer. The original uTorrent was just over 100KB and installed then ran in an instant.

These two refinements together are such a massive difference from any electron program that it melts my brain when people say that it isn't a problem to have a chat program feel like using windows 95 on a 386.

People say talk about needing cross platform programs, but something like fltk has everything most people will need and also runs instantly, while adding only a few hundred kilobytes to an executable.

I strongly disagree with the idea that lower level is better.

Yes, lower-level languages allow for programs with good performance, small executables, and so forth. There are many domains where they are clearly the way to go.

But higher-level languages allow for better safety, tremendous productivity, portability, exploration, and flexibility.

If you keep your data in an SQL database and you can easily query and update it in any number of ways that you didn't initially realize you wanted. If you instead keep it in hand-crafted C structs, you can probably provide awesome performance. for whatever you originally thought you needed. Once your needs go outside of that box, you'll have to spend significant development effort.

The correct choice depends almost entirely on the domain.

How about "being aware of what your abstraction layers cost, and being palpably aware of every needless contortion you create"

know what everything does. call if from up on high? fine, but only if you literally can trace that high level call down to the machine code it emits :D C compiler suites can do that no problem "gcc -S mycode.c"

For an appropriate dose of humility, so that you know that I'm not elevating myself here, but pointing out reality, check out GCC or LLVM source code.

Something like Lua or Berkeley DB can be defined inside your program in a matter of a few hundred lines of included library code, but what does it DO?

Bringing SQL and a database on board is rather odd for a desktop app, wouldn't you say? Configuration should be flat files, ideally, or managed via the apps gui, in which case an embedded database like Berkeley DB is usually more relevant. Your mention of SQL smacks of "all things are nails, always use hammers", to me at least.

Have you worked with the actual computer itself in any capacity? I mean ASM, C, C++, etc, but essentially being aware of what an ABI is, what types actually are (memory shape patterns so we can define physical memory in terms of our data structures) Javascript is not computer programming, but rather programming the browser, or it's disembodied transplanted javascript engine. the animal is completely different from physical memory and actual instructions.

Computers essentially manipulate memory structures. The further away from this you get, the more likely that your abstractions will be leaky, not fit what computers are actually DOING with your data, and this results in beautiful script driving janky machine code.

Seriously, while we all like to pretend that everyone is equally special, let's recall that someone is a VBscript for Word expert, and that this is basically a virtual machine that itself is just defined inside someone elses program. Technological stacks are defined in terms of semi-arbitrary made-up things other people made-up and that you just need to know how to use.

Sqlite is inanely well tested, incredibly lightweight, and will be more reliable than the vast vast majority of flat file configuration systems.

Ummm Context here is "desktop software" configuration management will be key-value and you needn't bring SQL in for that purpose.

Let's not bring "in-house web app" into the picture just yet.

The "all things are nails, always use hammers" mentality is almost explicitly what I am arguing against.

My mention of SQL was particularly deliberate. It's an especially successful high level declarative language with clear semantics. Implementations provide sophisticated execution engines for optimizing and efficiently running queries. It is quite a lovely separation of concerns that gives you great flexibility and good performance.

Obviously SQL would be a disastrous choice for, say, storing the pixel data in your video codec. Meanwhile, hand-coded C data structures and algorithms would be a disastrous choice for an inventory management system. Tradeoffs everywhere.

agreed.

a well DESIGNED technological stack WILL allow for high-level control of low-level structures.

Electron and Browser-based apps make a deliberate tradeoff that may be suitable for some kinds of apps (Balena Etcher, as I mentioned. You click a button and some process starts and alerts you when it's done.)

I would simply say that the OP should reverse the question: "in which cases can an electron app suffice for a desktop application" and not presume the death of desktop apps.

You are arguing against a point I didn't make. I'm not trying to rehash nonsense language arguments. I'm saying that many times the easy electron route is also correlated with programming that gives poor performance even outside of electron functions.

Not sure that I entirely agree there: I could easily imagine someone writing too close to the metal to stick to list iteration where a hash would be better and so on, unless it's prohibitively slower, whereas someone slightly higher would freely choose whatever they feel appropriate for the situation. They might often guess wrong and take a structure that is overkill for the typical dataset but the penalty for that will be negligible compared to the one paid for using a badly scaling structure on way too much data.

> You probably won't see someone writing asm but creating crazy O^2 algorithms

I watched a lecture by Bjarne Stroustrup that he gave to undergraduate CS majors at Texas A&M where he coded a solution to a problem using linear scans and then a "better" solution using better algorithms with better big O performance.

Then he did something interesting. He did a test on a tiny data set to demonstrate that the solution with linear scans was faster, and he asked the audience to guess at what data size the more efficient algorithms would start to beat the linear scan. After the audience members threw out a wide range of guesses he confessed that he didn't know. He had tried to test it that afternoon, but the linear scans outperformed the "better" algorithms on any data set that he could allocate memory for on his laptop.

IIRC he finished by telling them that professionals often do performance optimization the opposite of how the books present it. Using an algorithm with optimal big-O scaling isn't the optimized solution. It's the safe answer that you start with if you aren't bothering to optimize. When you need better performance, you evaluate your algorithms using real data and real machines and qualify your evaluations based on the characteristics (size, etc.) of the data.

You are focusing on an example and conflating it with the actual point that I'm making, which is that electron is not only slow, but compounded by slow programming in top.

That being said... I know exactly what you are talking about and it was always strange to me, because it was actually iterating through every time to find a value first, so the iteration through the linked list would always kill the performance. Even so, basic linked lists are practically obsolete. This is not a good example of algorithmic complexity, because the complexities were actually the same.

I agree, in part because of performance, but also in part because I value being able to bootstrap from source as much as possible. There are only a few projects seriously working on this, one being GNU Guix: https://guix.gnu.org/

The trouble with Electron apps though (and most Node apps) is the sheer number of dependencies. It's just infeasible to package them for a distro if you care about their dependencies being packaged as well - at least, not without the entire process being automated.

Slack desktop app is almost 1 gig in size.

On a whim I just checked how big the copy of Adium still lingering in my Mac is: 60 megs.

And Ripcord (a native discord/slack client) is a mere 40.

ooh I'll have to check out ripcord!

I use it daily. It's OK. It's better than having a full electron app/browser running, but it's fairly incomplete. (For example, in Slack I can't find a way to set my status.) I also have to reauthenticate every Monday morning which means launching Slack in a web browser to grab my credentials. It's a pain.

I've found it's great for Discord, and pretty good for Slack (although I've been using Slack in my browser now that it's become critical during WFH).

Unfortunately it's proprietary, but there's another native client called gtkcord3 [0] that seems to be progressing well.

0: https://github.com/diamondburned/gtkcord3

And Winamp is 4MB (after removing the stock plugins that I don’t need, like modern skins and the long-broken media library internet lookup stuff).

How big is Spotify now?

Spotify is 273MB (on Linux at least), 70MB for the binary and 137MB for Chrome, plus some other bits and bobs.

  $ pacman -Qi spotify
  Name            : spotify
  Version         : 1:1.1.10.546-4
  Description     : A proprietary music streaming service
  Architecture    : x86_64
  ...
  Installed Size  : 272.79 MiB

So at least it's smaller than Slack.

I have a noob question, but how do proprietary apps (IE: Slack) make it onto the AUR without having an official binary?

Both Slack and Spotify do provide Linux versions, even if not/less supported officially.

Thanks! I hadn't tried Arch yet, but I just saw the pkgbuild script on the site (didn't know it was there) and it makes since now :)

There’s nothing to really block much on the aur. There are some guidelines in naming and no duplicates, no maliciousness etc that are enforced, but that’s it. But anyone can upload a build script (PKGBUILD) for anything.

If you want to see how it’s done search the package name and AUR and you can see the build script right on the website.

TIL! Thank you :)

There are many PKGBUILDs on AUR that cactually download rpm / deb packages and unpack the binaries and deps from it.

iTunes, in all its bloated, much-maligned media-managing glory, is a mere 188 megs on my Mac.

I admire your words here.

I am on the other side, building electron apps, I appreciate the flexibility and ease because I would rather iterate on ideas then learn three different OS-hooks.

I do agree that memory usage is too high on these types of apps and we as developers can be lax about performance.

I agree too, and your average user is not going to care about the fact you've used Electron, or even know. It's a big win for development.

I disagree. I mean they may literally not know that your app uses Electron, but they'll certainly have the feeling of, "Oh, that janky app that doesn't quite work correctly and makes my system slow."

I think that might be true on Windows or Linux, but not on the Mac. It seems like Mac developers care more about making their application feel good to use.

Your average user has just come expect technology to suck nowadays. Go look around and many people are jaded by how poor things actually function.

When why not just use gtk or qt and call it a day? Electron is unnecessary.

Mainly due to them being both more tightly integrated to C++/Python than JS/TS for building desktop apps.

Yeah, but, honest question, why would you want to use JS if you didn't have to? It's like, the worst language possible.

When all you have is a hammer...

If you use typescript, the tooling is great and the parent also mention it so I assume they are using it.

Code reusability between browser/desktop/mobile is one. Easier to find developers, faster development speed due to ecosystem, previous experience/familiarity etc. I guess.

Maybe it is just your subjective opinion? I am pretty sure that there are people enjoy writing JS/TS over C++/Python.

If I were no experience for GUI development, I'd prefer to learn Web tech than Desktop tech like Qt because it look like more popular and versatile skill.

I would pick writing JS over C++ any day. Of course, that's just my opinion. I am sure yours differs.

JavaScript is actually not too bad. It lacks static types, but Typescript gives you one of the better type systems. But I'd take JavaScript over PHP or Bash any day of the week and twice on Fridays.

So quantity > quality?

Bonus points if it includes offline documentation. As nice as it is to have "updated" online docs, the reality to me seems to be defined more by broken links than by actual up-to-date documentation.

1 gig for Slack ? I count < 300 MB on my Windows C:\Users\[MY USERNAME]\AppData\Local\slack counting app-4.5.0 and packages folder

And currently taking < 300 MB RAM

185MB on mac.

"storage is cheap"

"memory are cheap"

"cpus are cheap"

Say the same people who spend a million on AWS every year

Reply on news.ycombinator.com