Hacker News Reader

Comment by lordofgibbons | Hacker News Reader

Honest question since I see a lot of similar comments on HN:

Would you rather not have this application exist at all? Because doing this with native UI frameworks is such a massively larger amount of work, it's not even comparable. Speaking from not-so-fond memories of working with Qt..

View on HN

From lived experience, creating a cross-platform application via abstracting the relevant native interfaces versus targeting web with all the _fun_ that entails are effectively equal levels of pain. Developing rich web apps isn’t free either; I needn’t go into the issues surrounding the revolving door of frameworks, contrived state management patterns that seem to change every year, the total lack of standard controls outside of built-in web elements that look awful which inevitably means that at some point, _you will_ have to be doing DOM manipulation for something that is otherwise built-in on an OS’s native toolkit, etc etc. And then when you put all of this together, you add yet another 500MB Chromium instance onto your user’s desktop and the thing feels like a social networking app.

I’m not going to pretend that there’s currently a better solution because for the current set of constraints everything sucks. .NET has a few up-and-coming frameworks for cross-platform UI but nothing mature like WPF was. Java still produces noticeably slow applications. React Native could perhaps get part of the way there, but as far as I’m aware that mostly targets mobile.

Yep, what's missing is a WebView standard for desktop, like Android and iOS provide. Where these apps are a thin wrapper around a system provided browser engine. And let the user choose the engine (gecko, blink, servo, ...).

The concern is not really around disk but memory, opening just a few Electron app instances is enough to bring a machine with 8GB of RAM to its knees. I’m almost convinced that this is some kind of a planned obsolescence plot.

A standard interface for web views would be great, I’d love to force everything onto a consistent version of Gecko, but really we need a new native cross-platform batteries-included framework with controls and layouts for 90% of standard business scenarios.

You can solve that with such a standard. Like when you're selecting the gecko engine it'll always run a Firefox process in the background, serving not just the normal Firefox browser frontend but also these WebViews. Kind of like ChromeOS does it. Of course every app will get it's own isolated browser process, but that's already the case when you open multiple tabs and it performs great.

No you won't, because it will be the same complains from Electron folks that the provided Gecko isn't the version they actually care about, and how testing is soooo hard when caring for anything beyond shipping Chrome with their application.

If it is to be done with Web technologies, than embrace the Web.

In this specific case, I rather use Google Sheets or Microsoft 365 on the browser, than yet another Electron app.

VSCode is one of the few that get a pass on my private computer, as some languages are only properly supported there, e.g. Powershell and Azure tooling.

Did you guys read the web page? Specifically, the part where it says “And to show Grist spreadsheets on a website without any special back-end support, your options include grist-static, a fully in-browser build of Grist.”?

I am replying to the remark "... another Electron app? :-(", regardless of how this one was actually made.

You said “In this specific case, I rather use Google Sheets or Microsoft 365 on the browser, than yet another Electron app.”. But right there in their README they tell you that you do not need to use an electron app; the spreadsheet can be completely contained in a webpage that you can use in your favorite browser.

Since you insist on the matter,

" If you wish to view and edit spreadsheets stored locally, another option is to use the grist-electron desktop app for Linux, Mac, and Windows. And to show Grist spreadsheets on a website without any special back-end support, your options include grist-static, a fully in-browser build of Grist."

This should never have been done, PWAs do exist.

Also there on the same readme.

That quote just proves my point. If you don’t want to use the electron app, use the web app. If you hate electron apps, then _ignore_ the electron app. Pretend it doesn’t exist.

The Electron app shouldn't have been written in first place, the web suffices.

No need to help Google take over the Web even further, besides the waste on local resources.

I agree, if it can be done in electron it should just be a web page. It will run faster be a tiny fraction of the size, and now that webasm exists, for the first time ever someone can compile native software to a generic form and run it in a JIT compiler on many different computers.

This is a bit of a false dichotomy territory already. It's not Electron or fully native. It's Electron, or Qt QML, or Avalonia, or Swing, or ... There are good choices which will not look 100% native, but are massively better in resource usage than Electron. (which is not native looking either) With Avalonia for example you can cover 3 major desktop platforms.

But specifically addressing "Would you rather not have this application exist at all?" - with more apps starting to go that way, it doesn't matter if they exist, because I won't have resources to run them. I've already dropped some electron apps for objectively worse alternatives, because I have actual work to do and 10 different Chrome processes cause swapping which prevents me from doing it.

> it doesn't matter if they exist, because I won't have resources to run them.

Honest question: what kind of hardware are you using? I run Electron apps on a 12 year old dual core laptop with HT disabled and 8GB of RAM and never had any issues. So I'm curious to learn what kind of hardware would prevent one from running an Electron app, while still being able to run the online equivalent (i.e. any modern web browser with scripting enabled).

16GB recent MBP. With browser, slack, spotify, vscode, terminal, etc. etc. all running on Electron and taking 11GB+, I started swapping when more demanding compilation kicked in. Ended up merging some of those into browser tabs and replacing others with lightweight alternatives - no more swapping.

The CPU doesn't really matter here that much and older hardware with 32GB would do better - it's the memory that gets impacted the most. Running "an Electron app" is not a problem. Running the 8th Electron app is.

See it this way

No application < Electron < Native app

Reply on news.ycombinator.com