[pier25]

The problem with Electron is that it's bloated by including a full browser engine and Node.

A couple of years ago I worked on an app that ran on 5 platforms (iOS, Android, Windows, macOS, ChromeOS). Initially we used Phonegap and Electron but then we created our own native wrapper that used the OS webview.

Our macOS app went from 100MB to 5MB of download size and the memory usage also went down considerably. IIRC correctly it consumed like 15MB of memory.

It certainly didn't look native but for our use case (education) that was not an issue. We were able to target 5 platforms with a very small team and the GUI was a single codebase made with InfernoJS and MobX.

[throwaway49496]

You prioritized app size, and that's great.

People prefer Electron because it gives them a consistent environment across operating systems, OS versions/update patch numbers, browser versions etc.

If you write your app to work in all possible combinations of the above - like you'd write a web page - you can use OS web view.

But not everybody wants to do that because it's not as straight forward as just writing your app and being able to fully rely on your environment. Perhaps you actually need features that aren't universally available in the OS web view yet, and performance degradation because of polyfills is not acceptable.

Also, OS web view is usually locked down more than Electron. It's basically a browser without the UI around it. Then you need to hack your own native bridge instead of just using whatever Electron made. I guarantee your version is going to be worse, you simply don't have the combined resources of the Electron open source project.

[scarface74]

> People prefer Electron because it gives them a consistent environment across operating systems

People don’t prefer an application that takes up more memory, drains battery life and that’s not consistent with their other apps. Developers may prefer it.

How many users are switching back and forth between Windows and Macs?

The same applies in the other direction. When I was a Windows user, I hated the iTunes interface because it felt like a bad Mac port. I was a former Mac (and current) Mac user so I could tell.

Even before that, the Windows QuickTime Player felt like a bad port.

[throwaway49496]

If the users don't want an Electron app, they won't use it and the developers will feel the need to change their ways.

Software development is not just about the users. Many Electron apps are single dev ventures. It's not easy to maintain multiple different platform specific apps even for a large enterprise. The larger the app the more difficult it becomes.

[palata]

> they won't use it

Except for all those popular Electron apps with lock-in effects, like Discord and Slack.

[throwaway49496]

Seems like the users think it's better to accept the performance degradation than to switch apps.

[palata]

Does it? My feeling is that users use whatever you give them. And then they buy a new device because theirs is "becoming slow". They don't say "wait, Slack is just a glorified IRC, it should work on my iPhone from 2008, I will just refuse to use it" because they need it.

There are no alternatives to the Slack ElectronJS Desktop app. That's the whole point: they don't want to maintain native apps. And they don't open their API to let others do it, I guess because that may hurt their lock-in benefits.

[scarface74]

> Software development is not just about the users

And this says a lot about why people prefer commercial alternatives.

[pipeline_peak]

Everyone loves to complain about how bloated Electron is. No one offers a solution that performs as well in supporting all of modern webs technologies.

[palata]

Make a nice API and let people write client apps that connect to it. Provide your official ElectronJS app next to that, and let the users choose.

I would definitely not use the ElectronJS Slack app if I had a choice.

[scarface74]

A better idea is not to use “web technologies” to create a native app

[pipeline_peak]

The tech industry begs to differ

[scarface74]

Google moved away from cross platform frameworks - including its own.

https://9to5google.com/2021/10/10/google-ios-apps-native/

Facebook moved away from cross platform web based frameworks for its apps years ago.

Microsoft’s mobile and desktop apps (besides Teams which also sucks and VSCode which is pretty good) are not using web frameworks.

[jocaal]

So some of the richest companies in the world chose to invest in the more powerful platforms, does that mean if you don't already have billions in the bank, you aren't allowed to create applications for users on multiple platforms? It is an enormous amount of work to learn the intricacies of multiple programming languages and frameworks and then to get feature parity accross all your native applications will literally take you like 3x more effort to implement them. Moreover, the reason these companies chose native is because it provides more features and the reason web technologies can't provide these features isn't technical, it's political.

[scarface74]

A smaller company’s ability to compete is not my problem. But why would I want to give any random web page that I browse to the same access to my computer or phone that I give an app that I choose to download that is much better sandboxed?

And most apps that would be suitable for PWAs are in fact free. How would Apple or Google benefit financially?

Besides most of the App Stores’s revenue comes from games

What happens when either Apple or Google introduce a new feature to their native platform?

[palata]

Nope, the product managers in the tech industry do. It's all about cost (or perceived cost). Web tech is more successful because it seems cheaper. Not because the resulting apps are better.

[stock_toaster]

revenue-per-employee has been at record highs in the industry for years now. Maybe companies could hire a couple more devs to make decent user experiences and native apps, instead of cheapening out and treating development like a cost center and using Electron apps as a way to just hire fewer devs (at the expense of a worse user experience).