Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tauri: Rust-based Electron alternative releases beta

tauri.studio

Post reply on HN
Print view View original

151–160 of 177 posts

Re: Tauri: Rust-based Electron alternative releases beta

#151

Post by distribot »

clejack wrote: post #98
distribot wrote: post #72

Earlier quoted context omitted.

I think if time on page and average session metrics suggested that's what people wanted, that's what we would see. It's like complaining about how the news reports on inane stuff.

Sounds like a case of bad metrics. Time on page when your goal is to get people to use your software/framework isn't meaningful. In fact, I suspect better communication leads to shorter times. Similar idea with news. The objectives of profit and conveying meaningful information aren't necessarily aligned. Disregarding the subjectivity of 'meaningful,' the advice 'know your target audience' is good from both a product…

I think that for both examples, having people's attention is a precursor to doing anything else. That's just my intuition though.

Maybe it is possible to have a landing page that people leave much more quickly but that is more successful. Maybe it is possible to keep your audience informed without them watching for very long.

Re: Tauri: Rust-based Electron alternative releases beta

#152

Post by bmn__ »

nim2020 wrote: post #2

Hey - I am nothingismagick aka Denjell, one of the founders of Tauri, and will do my best to answer your questions about the project, rust, wasm, etc. https://github.com/tauri-apps/tauri

No question, just a small commendation. It pleases me that you acted appropriately to the criticism about Tauri not being native and removed this previously advertised claim.

Re: Tauri: Rust-based Electron alternative releases beta

#153

Post by jdright »

nsonha wrote: post #15

I don't get the push for rust as a front-end language, it's very distracting with a lot of low-level features. Can we just stick with "best tool for the job"? Rust for performance-critical systems and, say, typescript for front-end? Using a single language for everything is a wet dream that always ends up in complexity and more work as you're fighting the "native" ecosystem.

You know, there are people like me that just can't stand Javascript. TypeScript is somewhat acceptable, but knowing Rust, I just prefer to use it anyway. It is just better.

Re: Tauri: Rust-based Electron alternative releases beta

#154

Post by oscargrouch »

Jweb_Guru wrote: post #78
fabiospampinato wrote: post #68

As a developer of an Electron app to me a competing framework that doesn't bundle its own rendering engine doesn't make sense, why would I want to trade control over how my app is rendered for ~100MB of disk space? I might as well just ship a website at that point, almost everything that makes Electron appealing comes from shipping your own rendering engine.

Order of magnitude memory reduction, not disk space, was the selling point last time I heard. And given how often I hear users complaining about memory consumption in Electron apps, I think that is something pretty attractive, if it pans out.

Not if you take one of the biggest selling points of Electron.

Im working on something not quite the same thing but that deal with all this, and being able to ship with a web rendering engine and not using whatever its on the system is actually better giving all the power, bindings, compromise you can make that you are unable when you can only deal with a abstract wrapper to every web rendering engine out there.

Lower memory footprint but with much less features and a generic "no sir, cant do such a thing.." as a answer to users that will need important features to ship applications with this.

Re: Tauri: Rust-based Electron alternative releases beta

#155

Post by pavlov »

hatch_q wrote: post #131
pavlov wrote: post #88

Earlier quoted context omitted.

Apple's brand new iMacs with the M1 CPU only have 8 GB of RAM. If every little desktop widget loads its own browser engine, most of that RAM will be spent on redundant copies of Chromium. If your Electron app is something that you expect users to run almost exclusively, then no problem. If it's just another little client app for some service, please consider a solution that would reduce its memory footprint.

And with WebView, RAM will be spent on redundant copies (instances) of WebView.

That's not how system frameworks work.

Re: Tauri: Rust-based Electron alternative releases beta

#156

Post by fabiospampinato »

francisl wrote: post #150
fabiospampinato wrote: post #149

Earlier quoted context omitted.

> Also electron require multiple node backend services which each eat memory like crazy (based on electron app I use). AFAIK Electron requires 1 Node instance (you can disable it for renderer processes and you can have 0 WebWorkers or only WebWorkers with Node.js disabled) which consumes like ~50MB or something like that, which probably accounts for stuff other than Node.js too, if the app you are using require multi…

> just badly written. Ins't the easy answer. Each time a dev want to ignore valid comments. I have the following electron app running: Spotify, Figma, VS Code, Discord, Slack. They all use more than 1 helper. Consuming between 600mb to 3.5gb. Slack is much better than it was. But I wish they switch to something like Tauri or Wails in the future.

Of those apps I can only say that VS Code is well written and that Spotify is junk.

Is 600mb too much for VS Code? I guess it depends on what you are doing with it and which extensions you have installed etc., if you are running a pretty bare-bones installation and seeing 1GB+ memory usages in VS Code please open an issue in their issue tracker and tag me (same username as in HN).

> Slack is much better than it was.

And that didn't happen by switching to the website approach, I think you'll be disappointed if any of these apps end up switching to Tauri or Wails without significantly improving their code too. Which is why I'd predict no major player will jump ship.

Re: Tauri: Rust-based Electron alternative releases beta

#157

Post by oscargrouch »

Zababa wrote: post #108
nsonha wrote: post #96

Earlier quoted context omitted.

I'm not saying that go and C++ have better type systems. I'm saying like rust, their type systems are built to aid the compiler. High-level languages like ocaml or f# have type systems made for domain modeling

I'm not sure I understand your point. Rust has ADTs, like OCaml and F#, and Go doesn't. Rust can be written almost like OCaml and F#, Go can't.

His point is that Rust is not user-friendly with a unnecessary cognitive load for user facing applications. I don't know why this comment section derails into the language properties and technical merits, giving its pretty simple to recognize that. The HN crowd might be above average and might tend to think that Rust is an easy enough language, but the reality for most people is that languages with the amount of complexity of the likes of Rust, C++ and Scala are not easy for the "average programmer" and we are not even talking about the people that just don't want to deal with unnecessary complexity.

Really, almost any GC'ed language out there is a better pick for this sort of task (except the ones that are poorly designed for this, like Go).

Re: Tauri: Rust-based Electron alternative releases beta

#158

Post by stdgy »

nklayman wrote: post #125
stdgy wrote: post #97

So what are the benefits to using Tauri over Electron? Are app sizes smaller? Is the memory footprint smaller?

Yes, much smaller install size and memory footprint. We have a comparison table on our readme: https://github.com/tauri-apps/tauri#comparison-between-tauri...

Thanks!

Re: Tauri: Rust-based Electron alternative releases beta

#159

Post by francisl »

fabiospampinato wrote: post #156
francisl wrote: post #150

Earlier quoted context omitted.

> just badly written. Ins't the easy answer. Each time a dev want to ignore valid comments. I have the following electron app running: Spotify, Figma, VS Code, Discord, Slack. They all use more than 1 helper. Consuming between 600mb to 3.5gb. Slack is much better than it was. But I wish they switch to something like Tauri or Wails in the future.

Of those apps I can only say that VS Code is well written and that Spotify is junk. Is 600mb too much for VS Code? I guess it depends on what you are doing with it and which extensions you have installed etc., if you are running a pretty bare-bones installation and seeing 1GB+ memory usages in VS Code please open an issue in their issue tracker and tag me (same username as in HN). > Slack is much better than it was.…

for my work, vscode take between 1.5 to 2.5gb. Nothing has change since start using it 4 years ago, and my experience is consistent with my coworkers. I keep using it because it 'feels' the best overall. No magical issue will fix that, node is memory hungry as is java.

Calling an app junk to justify is argument is unconvincing. Its still a widely used app that works as good as the competition. In the case of slack, their optimisation endeavour seems to cost them quite a lot. But sure I don't have the number. If they would have start the project in Tauri or Wails at the beginning, would that saved them the refactoring? I don't now. But we will need more team using that kind of alternative to gain the knowledge and real benefit.

At this point I rewriting a toy project from electron to wails and its great. But well, it's only a toy project.

Re: Tauri: Rust-based Electron alternative releases beta

#160

Post by oscargrouch »

politician wrote: post #29

Is anyone developing a cross-platform alternative to native OS webviews? The web hasn't been heading in a good direction lately.

I'm doing this.

One difference is to be able to ditch Javascript and use a native language(Swift is the first one) to talk directly to webkit.

The other difference is that the apps are "managed" as Chrome manages the renderer process, so in the end you have one manager process and one service process for each app and many process for the UI apps.

The problem with Electron is that for each app, it will need many processes, and if you have more than one Electron app running, it will eat all the resources.

With the architecture proposed, it will be more light as there will be just one instance of the manager processes, and unlike Electron they would not be isolated as they are all centrally managed, also the fact that it wont need to use JS, will also put less pressure on memory resources.

It also uses RPC so that every app have a API that can be callable by others. This in turn can make it form a "network of apps" where the applications can consume the apis of the other apps installed. The RPC service is local first, but can fetch things in the "cloud" if the application needs to.

For me this is my take on what "Web 3.0" should look like.

I have a 0.1 version here and i'm just finishing the final touches before launching it..

Edit: Also i forgot to mention that the distribution of the application and resources(database and files) is over torrent with DHT routing, so you can share a unique address and serve your own applications over internet without depending on domains or a third-party hosting it for you.

Post reply on HN