From time to time, I go to https://www.areweguiyet.com/ to check out how rust GUI is doing.
I've heard good things about Iced framework (the one that System76 is building their DE on).
By all means use it on desktop platforms, but it won’t get you an acceptable web version.
It's much less acceptable if you are Slack and still ship a slow bloated Electron app 10 years in.
This is not specific to Electron, it's a similar effect with every core technology, all the way to COBOL.
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.
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.
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.
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.
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.
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.
I could really feel the lag and the lack of snappiness when interacting with that UI.
Its webkit, safari also uses webkit? Why is it so slow?
https://github.com/tauri-apps/wry/issues/890#issuecomment-14...
Most of the Electron junk can be easily done as pure Web application, of course authors don't want to pay for hosting and ship a browser and server with the application.
There are a very tiny percentage of such startup ideas that really need features not available on a standard Web browser.
(I don’t know about Linux).
On Windows, and to a lesser degree on the Mac, this approach actually went pretty smoothly. But WebKit GTK introduces all sorts of problems -- having to tie into GTK's event loop even though you don't want it, dealing with distribution variances, event binding issues, etc.
I suspect the answer here for Tauri is that someone needs to expend the effort to come up with a good Rust crate bundling of Chromium or Gecko or etc that isn't tied into GTK. Yes, it would defeat the "just use the platform's webview instead of bundling" line, but really it would only be a concern for Linux.
They use WebKit GTK which is really not a good fondation IMO, its hard to test for all versions, its much slower than other browser, it has weird bugs.
In general the idea of not shipping a browser bundle is nice, in practice it doesn't really work for a startup. It's just too much unrelated testing and debugging work you need to do to support old outdated systems.
We were very excited to use tauri since we are a rust shop, but we are strongly considering moving to electron unless we get a way to bundle a renderer.