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

Tauri: An Electron alternative written in Rust

tauri.studio

Post reply on HN
Print view View original

181–190 of 438 posts

Re: Tauri: An Electron alternative written in Rust

#181

Post by CivBase »

alcover wrote: post #99
fabiospampinato wrote: post #38

Earlier quoted context omitted.

That's not the baseline though, the baseline RAM consumption for an Electron app is about 100MB. If you have garbage code as input it doesn't matter which stack executes it, you'll have garbage performance output.

Even 100MB is crazy. I know RAM is cheap but the absurdity of that amount is beyond me.

How many Electron applications do you honestly have running on your computer at any given time such that 100MB each is so concerning?

Right now I'm running VS Code and PyCharm, each with an one open project and one open editor. PyCharm is eating 1.8 GB while VS Code is only eating 130 MB. Funny enough, I see people complain about VS Code being a resource-hungry Electron app all the time but I've never seen anyone gripe about the resource usage of JetBrainz IDEs.

This isn't an excuse to Electron all the things, but browser-based GUIs do have their place.

Re: Tauri: An Electron alternative written in Rust

#182

Post by NetOpWibby »

nklayman wrote: post #126
Maledictus wrote: post #80

Earlier quoted context omitted.

Why can't they?

Servo is quite large and extremely difficult to build from source. We've tried to make it work with Tauri but decided it's not worth it, at least for now.

This makes me feel better about abandoning my own plans to do the same.

Re: Tauri: An Electron alternative written in Rust

#184

Post by efwfwef »

Klonoar wrote: post #149
brundolf wrote: post #143

Earlier quoted context omitted.

It also launched 8 years ago; the web has changed a lot since then. Edge wasn't even around until 2015, much less being used for webviews.

This sounds like you didn't look up and read the comment in question. Problems with cross-platform webviews stopped being the HTML/CSS/JS layer long ago; it's integration, availability, and rate-of-updates that are common blockers. Call me when Microsoft actually ships WebView2 with the OS.

if you would link to that comment it would be helpful

Re: Tauri: An Electron alternative written in Rust

#185

Post by silon42 »

afavour wrote: post #89
Maledictus wrote: post #80

Earlier quoted context omitted.

Why can't they?

AFAIK there are no V8 Servo bindings. So in theory (I don’t know Servo well at all) you could render a static HTML document but you’d have no DOM JS APIs to work with.

you probably wouldn't want it anyway. Using Servo only for rendering and using Rust for everything else would be preferable.

Re: Tauri: An Electron alternative written in Rust

#186

Post by sophiebits »

albertzeyer wrote: post #102
the_duke wrote: post #29

Earlier quoted context omitted.

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…

But why would the system webview be less resource hungry? If it runs in an own process instance, the only memory you safe is (maybe) the executable code (i.e. maybe 100MB max). Or you would need some common runtime which is shared across the OS, and somehow use IPC to it. Then you can potentially save some more memory. But I don't think this exists. And I'm also not sure how much you really would save. The advantage…

They’re not inherently more efficient (other than the reduced application size), but Safari and Edge are both more resource-efficient than Chrome.

Re: Tauri: An Electron alternative written in Rust

#187

Post by snemvalts »

munificent wrote: post #48
the_duke wrote: post #29

Earlier quoted context omitted.

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…

> Webviews are also a moving target so you need a big testing matrix. Even worse, an OS update after you ship your app can spontaneously break it on end user's machines without you knowing or being able to do anything about it. At least with the web, when new browser versions come out, you can fix your site since users essentially "install" it every time they refresh the page. But an installed app that runs on top of…

Need a docker for electron

Re: Tauri: An Electron alternative written in Rust

#188

Post by mdaniel »

nklayman wrote: post #126
Maledictus wrote: post #80

Earlier quoted context omitted.

Why can't they?

Servo is quite large and extremely difficult to build from source. We've tried to make it work with Tauri but decided it's not worth it, at least for now.

Do you have more specifics, and/or have you advised them of the difficulties? It seems to use the same "mach" build process as does firefox, and I build FF developer edition regularly (not every day, but damn near): https://github.com/servo/servo#normal-build

While investigating this, I have deep sympathies for whoever has to work with that taskcluster silliness because yikes that is some A++ grade obfuscation as compared to a .gitlab-ci.yml or .circleci or even the .travis.yml they migrated off of

Re: Tauri: An Electron alternative written in Rust

#189

Post by lcnmrn »

the_duke wrote: post #29
brundolf wrote: post #12

Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-detai... I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Interesting thing I just thought about: since users d…

A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…

An alternative to Electron should be built using Servo and Deno, both written in Rust.

Re: Tauri: An Electron alternative written in Rust

#190

Post by jlokier »

hctaw wrote: post #162
jlokier wrote: post #144

Earlier quoted context omitted.

> Meanwhile 16GB of memory Oh if only that was enough. My Safari is currently using 25.33GB¹ and and it regularly goes over 30. > 1TB SSDs cost less than $100 Ah, if only it was that easy. ¹ (According to iStat Menus; it's harder to see in Activity Monitor due to the separate processes.)

you can't buy an M1 mac with more than 16GB of memory so it seems like you have bigger problems

My Mac isn't an M1, but it does only have 16GB of RAM. Yes, it goes into swap when Safari grows like that. It's mostly ok even with several GB of swap used, but can slow down.

My solution is to restart Safari when it gets too bad, as it's obviously leaky.

For a long time I used Firefox, was annoyed at how slow it would get on a busy browsing day, and didn't realise the memory consumption of Safari (also open) was overloading the poor machine. One day I saw the stats and realised what was happening. Now I open only one browser at a time, and everything is much nicer.

If I decide to get another Mac (undecided), I'm holding out for an M1X or whatever with more RAM. 16GB isn't comfortable for my work any more. I'm not the kind of person who casually buys new expensive machines, so won't be getting the x86 32GB as an intermediate knowing I don't really need it, as I think it would be better to end up with both an x86 (which I already have) and an ARM going forward. I'm into code generation and portability, so that's better for me. And I like the idea of less fan noise!

Post reply on HN