I'm not familiar with Electron development, but isn't the code mostly JavaScript in that case? Does Rust have a meaningful contribution to the performance and the safety of the codebase here? I feel like Rust part would be "spin up the WebView". There is no code in the repository, so I couldn't check that out myself.
It apparently has a tremendous benefits: https://tauri.app/v1/references/benchmarks/
Then I think your beef is with the class of apps, not Tauri or Rust.
> Tauri still issues about 25000 syscalls at startup and needs about 300mb of ram for a “hello world” app
How many syscalls and how much memory does your web browser require on startup?
I'm not the biggest fan of JS apps, Electron, etc., but it's simply ridiculous to think this class of apps don't provide value.
It's become chic to yell about the good old days when it didn't take your editor a few seconds to startup, and I agree, but I think this lament actually requires an answer 1) in the form of code, 2) in a language everyone can learn 3) that runs on everything.
They absolutely provide value. I’m not questioning that. I’m just sad and frustrated by the lack of any better options for application developers.
We desperately need a good, lightweight, feature rich, cross platform application framework. Making something good will probably need an 8-figure budget at a minimum. Unfortunately nobody with that kind of money seems invested enough to make it happen. As a result, every computer on the planet is either slower or more expensive than it needs to be in order to run Teams / Slack / Discord / etc etc.
It feels like a coordination problem more than a technical problem, with users suffering the most.
Or those services should just expose a damn API and allow third party apps. I don't see what would be wrong technically with a lightweight Slack CLI app, a native macOS app, etc. Damn it's just about showing text on a screen... writing a third-party Slack client could even be a nice student project.
It just means that Slack needs to expose a proper API (unfortunately "proper" is not the norm in our industry), and probably there is a business reason to not allow it that I don't see right now (maybe just cargo cult or wrong assumptions, those are typical reasons behind business decisions).
The hello world for cross-platform Egui also written in Rust is a 19MB binary and uses 89MB of RAM.
Are you saying that "WebGUI" is the primary category you'd place this app in?
For end-users, the category is "chat apps". I grant the point, though, that these days there may not be any difference between the two.
> It's become chic to yell about the good old days when it didn't take your editor a few seconds to startup, and I agree, but I think this lament actually requires an answer 1) in the form of code, 2) in a language everyone can learn 3) that runs on everything.
While I ordinarily agree with this sentiment, the big pitch about this particular product is performance.
From the landing page, this is literally the first bullet point listed:
> Linen is 1000x more lightweight than alternatives. This means that we load faster, use less bandwidth and are more responsive
In this respect, I think that using 500MB on the 3MB transfer benchmark contradicts the 1000x more lightweight claim. I've never seen Slack or similar need even 10x as much RAM as the benchmark results.
Last I used Slack, it was using around 1GB of RAM in daily and active use.
At any rate, these are the things that get funded by VCs? It seems to me that the world is not crying out for a slightly more lightweight Slack alternative.
Some demand? Sure, for free tiers and low-cost tiers ... but how do they expect to monetise those free and low-cost users? The free tiers are usually subsidised by the enterprise tiers.
Now -- does this particular app solve this particular problem better than Slack? That's a fair Q, but, again, far afield from my point.
I have a real problem with this abstract beefing with other peoples' products and tech choices, that takes place in land that without alternatives. Show me the code for cross platform GUI development that doesn't look something like this. Explain how it's better than this, and how we should all be using it, instead of this. Until then, these criticism ring hollow to me.
Well, there's Qt that's relatively popular. Also WxWidgets. Java applications have had much success for x-platform GUIs (Jetbrains products come to mind) but is hardly considered lightweight (although much lighter than Electron-types).
Personally, I lean towards Lazarus.
All of the above (and I'm missing quite a few here) are insanely lightweight and performant compared to Electron-type implementations.
> Explain how it's better than this, and how we should all be using it, instead of this.
I did not claim that "all of us" should be using the alternatives. I said that, while in general I agree with using the quickets x-platform dev stack, for this particular application which claims "performance" as it's main goal AND further goes on to claim actual performance as a delivered result, I disagree that it is in any way as performant as it could be.
I mean, a quick win here would have been to use one of those alternatives I listed, maybe Qt. C++ GUI (using Qt) with Rust application logic would have probably been faster to develop than Html/Js + Rust, and the result would run just as fast (if not faster) and use less memory.
I'm inclined to use some of my precious free time to write a bare-bones x-platform GUI chat application, inventing my own protocol (like Linen did) just so that I have something to point at when invariably the claims of "performant" in electron-type apps is made.
So yes, in Electron 'the code is mostly JavaScript', but Tauri's offering 'let's do a piece of that in rust instead'. (And I suppose you could do the frontend in rust via wasm, but probably true of Electron too.)
It's not just Tauri itself as a development tool that's written in rust.