The truth us that once you have shipped Electron, there's no way back, the cost of switching is too high.

This is not specific to Electron, it's a similar effect with every core technology, all the way to COBOL.

Most electron apps are (mostly but not solely) a bundling of the web-app.

So the cost is less the cost of "switching" and more the cost of initially writing a native app.

In turn the actual question is how to reuse as much code as possible between the web-app and native apps without it introducing a lot of friction.

And one of the few reliable, nicely (developer) usable answers for this is currently electron.

For "business logic" there somewhat are already other answers, some languages run on most targets reliable and there is also wasm which often still needs a bit more tooling but has a lot of potential for such use cases (e.g. see Disney which AFIK does have their core business logic compiled to a wasm blob and then "only" provide UI/system glue to bundle it in on all platforms their streaming app runs on).

The problem is UI, you really don't want to reimplement UI and the mapping of non HTML/CSS producing UI to a mix of HTML/CSS on some platforms and native components on other often doesn't work grate so it's not surprising people decided to "just go with HTML/CSS everywhere". And if you are already there going with electron isn't "that" much more overhead.

This right here. Something monumental would have to happen for senior leadership to green light a rewrite, because that’s a massive project that will bring in no additional revenue.

That they are content with mediocrity, I have observed, but they deserve to be called mediocre. "It's Electron" is not an excuse.

What exactly makes Electron better for speed than say popular cross-platform GUI library X?

The massive advantage of Electron is write once -- with some extra overhead, perhaps 40% effort -- and you can ship the same app to web, mac, windows, ios, android, and linux.

I'd like to be explained why MS teams electron app is so different to the web version then.

I would like to know it, too.

MS seems to be using electron in the worst possible way.

I mean it's basically running an outdated version of the web version bundled into a even more absurdly outdated version of electron.

Given how bad the decision is it really looks like it's just for ticking of some checkbox and avoiding claims that MS is intentionally hurting other desktop system... but honestly the way they did it makes it look even more like that.

Through there are technical reasons AFIK:

- it seems to be that they have some custom native "call/video/screen-capture" code, which doesn't seem to provide any sustainable benefits but is less reliable in my experience.

- (speculative) for some time in the not that distant past (Chrome <v110) on Wayland desktops for screen sharing Chrome did only support an older experimental version of the protocol, locked behind an experimental flag. Through most distros set up pipewire in a way where the old protocol was still supported (on the fly converted) and even through the chrome flag was experimental it did work very reliable. So re-implementing pipewire support by hand would have been quite of an bad decision I hope Teams didn't do.

Also, the web version works better than the electron app (for me, ymmv).

Can't speak about other OSes but that is the case for me on linux.

And I hace seen quite a few people on windows who literally has to reboot because teams app was working erratically or was freezing and no amount of stopping/restarting the app would help.

Write once and provide a terrible experience to web, mac, windows, linux and an absolutely unusable piece of crap on iOS and Android.

Webviews are built on weakly, dynamically typed languages, which naturally have development speed advantage over statically typed languages in the happy path. On top of that you have multitude of frameworks even more optimized for the happy path. It is much faster to create an MVP of a GUI with web technologies.

Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch. Web, desktop, mobile. Almost one codebase can be used for all three.

Could you do the same with say, Java (and maybe soon with .NET)? Maybe. But web has a lower barrier for entry and faster speed of development cycle. Not to mention larger pool of developers available.

All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost. And once you get going, it is really hard to pivot your technology stack to something else.

> Also the same GUI code translates (kind of) to more platforms easier than writing it all from scratch.

With an exception of web there are very solid GUI cross-platform (linux, windows, mac) frameworks out there. Qt is even pretty good at targeting native look.

> All of this translates to two pretty much essential features for any startup: speedy entry to market (MVP) and low cost.

Yes, web technologies let you build MVPs faster, that's literally in my original comment. However, in order to provide quick MVPs these technologies inherently sacrifice long term maintainability.

QT is just gonna be untenable for most people. Learning C++ is hard enough, but learning QT is basically a different dialect of C++, and I can't even say it's worth the investment.

Third time I am hearing about the "happy path" lately. This phrase seems to become popular quickly.

Well, s/Electron/WebUI generally, the conclusion that I came to last year was beyond Qt there really isn't a decent cross platform UI toolkit out there that really handles all the nitty gritty details like accessibility, proper GPU acceleration, etc. And Qt comes with its own normative lifestyle assumptions. And there is this huge community of HTML/JS/TypeScript developers and a pile of UI frameworks for them.

So if you're looking to build a cross platform desktop application, you want to also be able to service it on web, and you want to be able to hire beyond the limited Qt/C++ talent pool, it just makes sense.