[yojo]

It's not a new or scary thing, but it's way more expensive (in time or money) than relying on "it looks good on my machine, so it looks good everywhere."

I've worked on large consumer-facing web-apps where we had a dedicated QA team (and/or contracting firm) that runs visual regression testing on multiple platforms and browser versions. As a solo developer, I have no interest in being that team for my hobby project. So the tradeoff with Tauri for me was "accept that I will ship obvious UI bugs" vs "accept that I will ship a bloated binary."

Reading anecdata on forums, it seems like the only people who get up in arms over an extra 200MB are HN readers, and my app isn't really targeted at them.

[littlestymaar]

> "it looks good on my machine, so it looks good everywhere."

It bas always been a fallacy though, as with CSS the end result can depend on the DPI scaling and the size of the display (unless you make sure it doesn't, but then you need to test different setups to be sure).

[mort96]

Well, they're right to point out that it removes a lot of inconsistency though. For example, today I was working on an app which used some Unicode characters as icons in buttons, and they look perfectly centered in the button in Firefox but weirdly off-Center in Chrome.

I never managed to find a set of CSS properties which made it look good in Chrome tho. And if it was a more serious project I'd probably have used SVGs instead of Unicode characters.

[littlestymaar]

Sure, the closer your config is from the actual user config the fewer issues you'll get, but I wanted to highlight that even with electron you ought to test on different configurations.

[mort96]

Oh, yeah, certainly. Even when I've made dinky little Electron apps I've had a Windows machine ready (I otherwise use Linux and macOS) just to make the Windows binary and do some rudimentary acceptance tests. You can't get away from testing on all your officially supported configurations.

[cosmic_cheese]

It’s an unpopular take I’m sure, but I really have to question shipping binaries for platforms that I can’t or won’t personally test. Between platform intricacies I don’t understand, unaddressed papercuts, and limited ability to debug issues, the end result is very likely to be underwhelming and/or frustrating for users of that platform, and as such if the app is paid those users are disproportionately unlikely to convert and more likely to churn. The only real benefit I see is an extra platform icon lined up on the marketing page.

[wtallis]

There's also the simple fact that shipping an identical UI on multiple operating systems is obviously wrong for a least some of those operating systems (and maybe all of them). You don't have to worry about "platform intricacies" because a web-based cross-platform UI toolkit is going to get really basic UI conventions wrong.

[cosmic_cheese]

It’s not only UI design/conventions being covered, but also things like quirks with the system’s audio, compositor, window manager, etc depending on what your app does and which technologies it uses. If the dev doesn’t understand these things about a platform, they’re walking into a minefield by supporting it.

[ChadNauseam]

At this point people are more accustomed to chrome’s conventions than the native UI’s conventions in most cases

[int_19h]

But there aren't really many "Chrome conventions" to speak of. Every web app (and Electron app) necessarily has to reinvent a lot of wheels that desktop apps get for free from the underlying OS. And sure, there are component libraries for that... way too many libraries, each of them doing everything slightly differently from others.

[Capricorn2481]

> Reading anecdata on forums, it seems like the only people who get up in arms over an extra 200MB are HN readers, and my app isn't really targeted at them

I think it's good to be wary of overly sensitive advice that regular users don't care about. But would a regular user realize they have 10 electron apps running and their ram is maxed out all the time?

The argument against Electron isn't just a single bloated binary, but everyone shipping an app that uses way more RAM than necessary.

[yojo]

That's a fair point. My app (and possibly the OP's) is built assuming it is the user's current focus and priority, and that you'll quit it once you're done with the task. I don't feel bad about asking for a chunk of RAM for a focal app like this, but I would feel differently if I was shipping a background tool or small utility or something.

[mort96]

Especially macOS is built on the assumption that you rarely "quit" apps. When you close all of an app's windows, it remains running. You actually have to hit cmd+q or right click and hit "Quit" in the Dock to really quit an app.

In other circumstances too though, it's not great UX to demand your users quit your app once they're done with it because it eats too many resources just being idle in the background. It's an issue I have with both Electron, where idle apps waste tonnes or RAM, and with many Rust UI frameworks, where an immediate-mode architecture means they'll be consuming CPU on the background.

[ksherlock]

Electron doesn't seem to support it (and even if it did, I suspect most electron developers wouldn't pay it any mind) but...

NSApplicationDelegate's -(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender; method exists so an application can, uhh, automatically terminate after the last window closes.

https://developer.apple.com/documentation/appkit/nsapplicati...

It's not 100% consistent but if you look at Apple's applications based on single window (calculator, system preferences, etc), closing the window quits the app.

[mort96]

Electron doesn't automatically exit when the last window is closed, and the Electron getting started guide (https://www.electronjs.org/docs/latest/tutorial/tutorial-fir...) recommends this code:

    app.on('window-all-closed', () => {
        if (process.platform !== 'darwin') app.quit()
    })

Most Electron apps probably do exactly that. It would feel extremely out of place for a macOS app to quit just because you closed a window.

[jonhohle]

The function has been available for a while, but auto-closing system apps is a relatively recent change.

I can’t find obvious reference or when Apple started changing this, but it seems related to background app killing that is done now as well. I’m still not sure how I feel about it, but historically that wasn’t common for Mac apps.

[wtallis]

The ability for an app to keep running without a window was a godsend back in the days when we were all running on hard drives and large apps had splash screens to amuse you during their multi-second launch process. If you were done with a particular document but not done with the application as a whole, you could simply close the window and next time you needed to open a document in that app you wouldn't have to sit through the splash screen again. Unless it was an app with a cross-platform GUI that didn't support this model.

Nowadays, apps closing themselves or being closed by the OS automatically is reasonable in a lot of cases, but Electron apps tend to hit the cases where it still is valuable to operate with the classic NeXT/OS X document-based app paradigm.

[jonhohle]

Part of it is respecting your customers regardless of whether they are aware of your crappy electron app consuming all their RAM and draining their battery or not. If I went to a mechanic (car analogy incoming) that repaired pressurized lines with duct tape instead of hose clamps because I wouldn’t care as long as the car worked, I would be upset, regardless of whether or not it got the job done.

Take pride in your work and respect the people using it.

[izacus]

At one of my jobs we actually measured those differences and even 10s of MB in app size increase moved user download, use and update metrics (negatively).

I think the person you're responding to didn't actually measure if their claim is true.

[Aeolun]

> it seems like the only people who get up in arms over an extra 200MB are HN readers, and my app isn't really targeted at them

Tauri however, is.

[sroussey]

Some of these apps then download huge models these days and the total space savings kinda vanishes.

[brulard]

Absolutely. HN is unnecessarily full of "electron always bad" mindset. It makes sense for so many use cases.