Native is not a tool, nor a goal. Native is an implication of a user experience and performance. Very few non-native applications provide the same experience and performance as native applications (although there are exceptions and it's not always black and white).

"Native" is the implication that a certain level of comformity is present: the user generally gets an experience that is similar to other native applications.

As you develop with native APIs, and when you follow the best practices for the platform, you end up with a product where the UX is much easier to grasp for the user. Non-native solutions very often have different UI/UX patterns, which leads to users having to learn these patterns before the application becomes understood by them.

> the user generally gets an experience that is similar to other native applications

This sounds like the goal you want to achieve using native as a tool.

But anyone who struggles to grasp non-native UI and UX is going to struggle to interact with the modern IT environment as there is no standard for web-apps.

If I order a cup of tea, you could argue that what I actually want is to achieve the goal of drinking something which has the taste, smell and general nutritional profile of tea.

Theoretically, there might exist a cup of coffee that achieves this goal. But I've never seen one, and if you serve me coffee it's almost certainly not going to achieve my goal.

For me personally, it's having a set of UI widgets as consistent as possible with everything else on the platform as the primary concern. Secondarily it's performance / battery life.

I think this has long stopped being a design goal. The OS is not the primary platform any more which everything orients around, it's an access point to the web. Products are determining design language now.

People don't expect Google to look 'like Windows' just because they're on a Windows OS, they expect Google to look like Material apps across all platforms. There's not 'windows spotify' or 'android spotify' but they expect the app to look the feel the same everywhere, and in that way companies actually benefit from using Electron.

In my experience the people who decide these things talk about branding. Not user expectations. Phone, tablet, and desktop apps have different interfaces anyway. And few people use more than 1 desktop OS and 1 mobile OS

I think this argument used to make sense to me as well, but since most apps I interact with are web apps in browsers these days, most of my interactions aren't with native widgets anyway and I don't really care anymore.

Many of us have been bludgeoned by web apps to the point of not caring any more … most web apps are slow, twitchy interfaces that shift constantly and the industry loves it because it allows them to utilize the armies of (used to be cheap) web developers but at a heavy cost to the user experience

As someone who switches between three platforms, I like that Electron apps are consistent and in sync. Back in the day when I was using Skype, I could never get used to either.

I don't know what Slack or Teams would look like with native UI components, but I am pretty sure I would consider it inferior to what we have at the moment. The possibly improved performance and memory footprint would be nice but not enough for me to care about.

> "What's the underlying goal you want to achieve"

Responds to user input quickly enough to not be frustrating.

Yes. Using laggy apps, I don't feel like working, it feels like a struggle, hence frustration.

>What's the underlying goal you want to achieve

Performance, small bundle sizes and native UI widgets. And judging by all of the Electron apps failing in these departments, I guess you really do need native apps.

It's the memory bloat that stands out to me. Many modern laptops have 8GB of RAM. (Curiously this number hasn't really changed in the last 9 years.) 500MB of bloat isn't a trivial fraction of that.

Also, an application that runs constantly in the background, is under a greater obligation to make efficient use of system resources.

> judging by all of the Electron apps failing in these departments, I guess you really do need native apps.

I'd put that differently: solutions heavily based on web technologies seem to consistently fail to be anywhere near as efficient as solutions that use conventional toolkits. (Sometimes someone will suggest this isn't true if the web-based solution is well implemented, but they are never able to give an example of such an application.) On most platforms, Qt doesn't count as being truly native, but it's still far more efficient than Electron.

> small bundle sizes

Space are not precious anymore. Nor is bandwidth.

BestBuy sells some Windows laptops with 64 GB eMMC. Space is precious on those. Chrome devices often ship with 16 GB; if Microsoft could make Windows viable at that size, they could push the absolute low end prices down a smidge and keep more users.

I get 60 Mbps down and an upgrade would be $50k. Bandwidth is relatively precious to me.

> BestBuy sells some Windows laptops with 64 GB eMMC.

I would suggest that people are likely not attempting to use enterprise-grade collaboration software on these machines, so that's not a problem.

Except it's not enterprise-grade.

https://www.theverge.com/2021/5/17/22439924/microsoft-teams-...

Both are very expensive on mobile.

Says who? A Surface Laptop 4 comes with a 256 GB SSD. And the Surface Pro 7 comes with a 128 GB SSD.

Something that's a resource hog will likely consume a lot of battery as well. That's a big deal for something you want running all the time.