Hacker News Reader

Comment by fermienrico | Hacker News Reader

The web has become truly awful and it’s invading desktop apps. We need to refactor our technology stack.

Most native apps I've downloaded are well into tens or hundreds megabytes. I just tried a few big popular sites with caching off and none of them downloaded more than a couple megabytes of javascript. I'm really skeptical of the popular wisdom around here that web dev is doing something especially egregious when it comes to build sizes or dependencies.

The browser is where the hundreds of megabytes vanish to when you use a JS app instead of a native one.

That might still be better (I'm undecided, personally), but it's worth recognizing that heavy native app is still there, just shared with a lot of other JS apps.

You could say the same about system libraries/binaries every native app needs to run

Native apps can share libraries at run time. I'm no electron expert but I'm assuming electron apps only can share dependencies at build time at which point they would be copied into the executable so they really wouldn't be sharing.

Valid point, for sure.

Slack: usually ~300MiB of RAM for one account. The Ripcord [1] Slack/Discord client written in C++ and Qt: currently using 33MiB. Qt is not the native toolkit on Windows/Mac, but Qt apps typically follow platform conventions far better than Electron apps.

This also voids the argument "we need Electron, because it reduces development costs, and we can get truly cross-platform apps". Ripcord is written by a single indie developer and runs on Windows, Mac, and Linux. Imagine what could be done if Slack employed a team with 10 Qt developers.

Most web apps are egregious. The problem is that there is a whole generation that is not exposed to Delphi or Qt Designer and have the false believe that developing web apps is an order of magnitude easier. It's only an order or magnitude easier for them, because web tech is the only thing they know. Heck, I was writing GUI apps as a 12y/o with Delphi.

[1] https://cancel.fm/ripcord/

People don’t care. The vast majority of people don’t ever use their computers for anything heavy, so it’s not like saving a few hundred mb of ram is going to be noticeable for them. It’d be nice to have a lighter, more performant app but if the cost is that it looks like what you posted (no offence to the dev of ripcord; IMO qt and gtk stuff always just looks super outdated) then I’d bet most people would prefer the more modern/pretty looking app.

The vast majority of people don’t ever use their computers for anything heavy, so it’s not like saving a few hundred mb of ram is going to be noticeable for them.

They will definitely notice. E.g. baseline MacBooks (which is probably what most people outside developers buy) still come with 8GB RAM. If you subtract the OS, video memory, and some disk caching. There is not that much left on modern macOS (or Windows).

Having Slack + Skype in the background and some tabs open with modern web sites/applications can easily much a few GBs of RAM, slowing down quite a lot of 8GB machines. I guess most developers just don't notice, because their employer give them development machines with 16 or 32GB RAM.

People don’t care.

They don't care because they don't understand. They will just believe that their computers are slow and that they have to throw more money at it. Or they just buy an iPad and it will feel fast, because Apple does not allow every application to ship and run its own web browser.

no offence to the dev of ripcord; IMO qt and gtk stuff always just looks super outdated

That's because the developer decided to use their own theme. I have made a few Qt apps and on macOS and Windows you can barely distinguish them from a native app, unless you know where to look. Fully agree with Gtk+ though, it does not follow platform styling and conventions and is very slow on macOS (don't know about Windows).

It's worth mentioning that apart from Javascript, there is nothing 'web' about React Native. To put it simply: You use Javascript to control native components. Electron and React Native are wildly different. React Native is set up to look like web development, but it is not. It makes it easier to get started, but over time you'll have to appreciate the native platform underneath.

Today I installed an Electron-based terminal emulator and started seriously questioning my life choices.

I have the opinion that UI should not be async - meaning if there is some processing going on, UI elements should be disabled from interaction until the function returns. If it is a web query, I think that's fine. When applications start adding queues and jobs, UI feels "springy" instead of "snappy". User is waiting for some feedback of how long something is going to take, instead the user assumes that job is done (due to lack of feedback) and tries something next - this action is now in the queue. And then user waits... wait... and all of a sudden all queued processes return. This is not human centric design.

Yes! Obviously long-running operations should be asynchronous, but the assumption that all operations should be treated as long-running is wrong. Specifically, typing feedback and button feedback should be synchronous, and should be done directly in the UI loop.

I understand the rationale for going async -- you can never be sure exactly how long anything will take, and invisible things like memory management and caching can blow up your runtime; and if you get synchronous operations wrong, that leads to spinning beach ball cursors and “app not responding” errors, which are even worse than lag. But in that scenario, an async app isn’t going to perform any more usefully, you’ll just get a blank or frozen screen instead of a beach ball.

Reply on news.ycombinator.com