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

Tauri – Electron alternative written in Rust

tauri.studio

Post reply on HN
Print view View original

291–300 of 435 posts

Re: Tauri – Electron alternative written in Rust

#291

Post by throw10920 »

fastball wrote: post #191
jokoon wrote: post #94

I have a hard time understanding why platforms like electron are so popular. The predictions from Gary Bernhardt seem to really be true, in the future everything will be javascript. I wonder if somebody actually tried to make an OS that only has a browser, that's what Chrome OS actually is, after all.

We built our product for the web. People wanted our product as a desktop app. So we wrapped it in Electron and now we have 3 desktop apps. People wanted our product as a mobile app. So we wrapped it in Capacitor and now we have two mobile apps. There are just two of us building this product.

What prevents you from using Qt to do almost exactly the same thing?

Re: Tauri – Electron alternative written in Rust

#292

Post by SavantIdiot »

throw10920 wrote: post #289
SavantIdiot wrote: post #216

Earlier quoted context omitted.

Because it saves my company 66% in development costs.

It takes 3x as much effort to write an application in Qt than using web technologies?

I wasn't even talking about the penalty of writing a Qt application in C++.

That's a different penalty. Qt doesn't really compare with what can be done with a good UX/UI dev on the team, and in much less time. And there are far more front-end devs than Qt experts.

Re: Tauri – Electron alternative written in Rust

#293

Post by synergy20 »

dangoor wrote: post #272
synergy20 wrote: post #247

Earlier quoted context omitted.

I just ran vscode on ubuntu and checked its memory usage, you're correct that vscode brings its own chromium instead of sharing any libraries with my running chrome. Wry said to use 'default web engine', which under Gnome is libwebkitgtk(i.e. webkit engine), that is different from its default browser firefox which uses Gecko as the engine. so Electron and Tauri both will bring their own demanding/heavy cpu/memory nee…

Neither is as lightweight as native, but if you've got a collection of apps running against OS webviews vs a collection of apps running against their own Chromiums, it seems like the webview ones would share at least some memory. (It could just be that all you gain is disk space and smaller downloads, which I agree isn't that much of a win)

When I was playing with Tauri I had to install libwebkitgtk etc for it, since neither firefox nor chrome brings in that dependency. Unless you're using some gtk browser that disk space was not saved by Tauri at all.

Anyways other than Tauri is a Rust-flavor, on the resource usage side, it shall not have much difference from using Electron, which uses Nodejs.

Re: Tauri – Electron alternative written in Rust

#294

Post by staticassertion »

Karunamon wrote: post #279
staticassertion wrote: post #262

Earlier quoted context omitted.

Unless you're seeing other processes crash because of a lack of RAM this isn't an issue, your OS will page things in/ out, including in Chrome, based on memory pressure.

Yes it is an issue. Under high memory pressure, we start digging into swap, and at that point, the UI is starting to significantly chug. Worse, this often happens when there's plenty of cache to evict. I can and have restored a nigh-unusable desktop to normal operation many times with a painfully entered `echo 3 > /proc/sys/vm/drop_caches` from a new TTY, instantly resolving the pressure and giving me time to find an…

> Under high memory pressure

Just to again note that just because a program says it's using N MB of RAM doesn't mean that all of that RAM is actually paged in. Every thread you execute has an 8+MB stack but most of it won't get allocated for the majority of programs.

> we start digging into swap, and at that point, the UI is starting to significantly chug.

Only if you're constantly swapping in and out of swap. Just putting something into swap and never retrieving it won't case issues.

I'd generally recommend disabling swap altogether though and just letting OOM take out misbehaving processes.

This isn't all to say that using less memory is 'bad', but when people say 'oh that program is such a memory hog' I wonder if they might be measuring incorrectly, or not realizing what it's doing with that memory.

Re: Tauri – Electron alternative written in Rust

#295

Post by liketochill »

heurisko wrote: post #275
pjerem wrote: post #124

Earlier quoted context omitted.

I'm not sure you really remember. With 56k dialup, downloading 650MB could easily take days. Downloading 1MB could have taken 3 to 4 minutes. 60MB, even today, is really big when you have to download it while boarding a train or with poor connectivity (even in rich countries, just being in a metallic building is enough for 60MB to be painful to download.

I remember leaving the computer on to download 650MB overnight, which used to be an ISO for an operating system. It was usually finished sometime the next day. And 60MB would have been a couple of hours, not bad to wait for some software. It wasn't prohibitive to do this. Indeed, I seem to be back at square one, as downloading a AAA game for me once again takes about a day.

650,000 kb / 5 kb/s = 36 hours

Re: Tauri – Electron alternative written in Rust

#297

Post by kbelder »

bredren wrote: post #234
niyaven wrote: post #84

Earlier quoted context omitted.

> If not, what's wrong with it "spread[ing]" everywhere? Because then it's a monopoly. I'm taking shortcuts but having a single browser engine controlled by a single company means that you rely on that company to define what is tomorrow's web like.

Without this kind of thing happening at times, we might still be using Flash.

Electron feels to me a lot like stand-alone flash apps used to feel.

I get that same feeling when I open an program using it; kind of a 'oh...' slight disappointment. I get that it makes sense sometimes for a developer to sacrifice performance and size for ease of development... but as a user, it feels like a loss, a sign the developer will be taking too many shortcuts, or that I just won't like their general design philosophy.

Re: Tauri – Electron alternative written in Rust

#298

Post by sbarre »

Chris2048 wrote: post #131
sbarre wrote: post #109

Earlier quoted context omitted.

Aside from the improvements to project timelines, Electron and similar products are popular because they improve the developer experience, and in 2022 the developer experience is what matters the most to many software companies (yes, in many cases ahead of the customer experience). DX directly drives engagement and retention, and good developers are hard to find (and keep!). And like it or not, there are more and mor…

> Electron and similar products are popular because they improve the developer experience > more and more developers entering the industry with web-only training aren't these very different things? Is Electron popular because web-skill are so common, or because the dev experience is better - I sceptical of the latter, as I find JS very dependant on framework/ecosystems for compatibility.

Sorry if I implied those were tightly coupled. I do think they are related but more loosely than perhaps I meant, and not exclusively.

Electron improves DX for all the usually stated reasons (build once for many platforms, etc) but I do think there is a connection to the fact that a lot of developers out there are learning web tooling, and if a company wants to put out a desktop app in 2022, it's an easier (and therefore better for DX) path to use something like Electron or Tauri - where devs can use the skills they already have - than try to either upskill or hire a team that can build native apps on all your desired platforms.

Re: Tauri – Electron alternative written in Rust

#300

Post by ReleaseCandidat »

thomascgalvin wrote: post #235
rk06 wrote: post #154

Earlier quoted context omitted.

would you rather have three teams developing one app on three platforms (windows, mac, linux) or one team developing one app for all platforms? It makes perfect business sense to use electron. It opens paths which otherwise would be very costly and hence infeasible.

> would you rather have three teams developing one app on three platforms (windows, mac, linux) or one team developing one app for all platforms? I would rather have one team developing a cross-platform application in a language that isn't Javascript.

> I would rather have one team developing a cross-platform application in a language that isn't Javascript.

So, use one of the many languages that compile to JS. Starting with TypeScript. Or (alphabetically) ClojureScript, Elm, PureScript, or Rescript.

Post reply on HN