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.

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 electrone.

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 they 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 AFIK.

- (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 stupid 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.

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.