Hacker News Reader

Comment by bayesian_horse | Hacker News Reader

I think the major benefit of a native/compiled language like C or Rust over interpreted/JIT ones like Python or Javascript for desktop applications is the overhead in terms of distribution size and memory consumption.

Speed doesn't come into it that much. Current desktop systems are fast enough such that most GUI manipulation just isn't a speed bottleneck, except for things like realtime graphics or something.

View on HN

I strongly disagree.

Complex web UIs in general have perceivable latency and are perceivably sluggish for me. I noticed how bad the problem is when I noticed some latency in responding to mouse clicks in a React application I was developing. After unsuccessfully trying to bring it down, I compared it to a handful of other web apps I use routinely, and then a handful of native desktop apps. When I did that it became depressingly obvious how conditioned I am to the poor responsiveness of these UIs.

For the record, this is all on a 4-core i7 machine with an NVMe SSD and 16GB of RAM. It's fair to say that the average machine where these are used is far lower.

Well it depends on the app :-) if the app is running something time-consuming in the hot path of every render, then yes it will be laggy. You can run the same risk even on a native app.

I animated SVG elements at 60fps with React. So yes, React can be pretty fast and low-latency.

And obviously, most users don't seem to care that much. Otherwise you wouldn't have these web applications. Developers would spend the multiple amounts of work, gladly paid by their employers and investors and gladly reimbursed by the users through licensing fees, necessary to make hot-to-the touch user interfaces for everything we use computers nowadays.

It's attitude like this that makes my 8GB of RAM laptop barely able to handle Spotify and a few tabs in Chrome.

And now consider that developers would have to spend a multiple of their time on every little app. And they will be more buggy and insecure. And you'd often need to trust the binaries and install them.

Rust drives all of that down somewhat. Also webassembly will bring the ability to trust almost-native machine code.

Also: I said the main benefit of compiled languages is the memory overhead. If your 8gb of RAM can't handle multiple Chrome tabs, it's because of the memory overhead, not because javascript is slower. Most of the tabs aren't doing anything to the CPU most of the time.

What I really wish is that these Electron apps could share a common instance of Chromium. That would help the memory consumption issue a lot, but I'm not sure how to implement it best.

Couldn't they just run like a regular website, except be available offline? Then you could just open it up in your browser, so only one instance of Chrome/Firefox is used. Not sure how hard it would be to allow electron apps to run like that, but it seems like they are basically just websites as it is, given that they run on Chromium, maybe it would be harder for them to work with the OS filesystem though.

For the electron apps I use, they are generally available online as a website anyways, so I just use that, and get the whole common instance thing for free.

Electron apps have unfettered access to the system (through node.js), they aren't just webpages.

Well, Electron is essentially a server and chromium, so there should also be a way to execute nodejs code inside the browser then... which would break sandboxing.

I think this isn’t really a problem of Electron, but more to Chromium. We bundle python inside the binary and it’s fine. I don’t think I’ll hate command line programs that embed nodejs inside the binary.

It’s the Chromium that’s problematic, and just by switching Chromium to the native WebView will make Electron apps much, much more lightweight.

Often they can, if they don't use certain features not yet encapsulated in webapps.

Most of it is about trust, and you'll see certain web APIs built around asking for permission to access the camera, or image files or whatever.

Desktop apps often can't really trust each other. It's not a problem right now, but if you could XSS something into a game or social app which, with user-level permissions on your desktop could remote-control (for example click-simulating) your electron banking app, that would be really bad. Just a contrived example, but with great power comes great exploitability.

Cocoa eat almost same amount of memory as Electron for a decent size app.

That seems like a very bold claim on the face of it. Do you have any examples?

Reply on news.ycombinator.com