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

381–390 of 435 posts

Re: Tauri – Electron alternative written in Rust

#381

Post by jcelerier »

yayr wrote: post #356
jcelerier wrote: post #208

Earlier quoted context omitted.

> Let's just imagine for a while what UI would look like if we only had Swing (Java) or QT (C++) yes, Telegram looks so bad right ?

if you like the pricing and licensing, functionally QT may be for you. The web frameworks mentioned on the other hand are free to use for everybody and anything.

Qt is LGPL. You know what else requires you to respect the LGPL ? Electron becauses it is built mainly on LGPL components (Blink, FFMPEG to name the biggest ones). If you are ok with the license of Electron you are ok with the license of Qt.

Re: Tauri – Electron alternative written in Rust

#382

Post by ummonk »

forgotmyoldacc wrote: post #3

If anyone wants to know how it works: > [leverages] WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux. So cross-platform compatibility isn't guaranteed, unlike Electron. https://github.com/tauri-apps/tauri

And here I was hoping it would use Servo.

Re: Tauri – Electron alternative written in Rust

#383

Post by kaba0 »

microtonal wrote: post #267
adwn wrote: post #250

Earlier quoted context omitted.

> So efficient for you, but 1000x more resources everywhere it runs. And yet, to the people who do use their app on the desktop, this is obviously a preferable situation to not using the app – which would probably be the case had the developers decided against Electron.

And yet, we have single indie developers writing multiplatform Qt [1] and macOS native [2] Slack apps. Last time I checked, Ripcord used 30-40MiB RAM, a small fraction of the official Slack client. Writing native apps (or a Qt app) would well be in reach of Slack. In fact, they already have native apps. E.g. Slack for iOS/iPadOS is native [3], just allowing M1 Mac users to use the iPadOS version would most likely be…

Exactly this is what I don’t get. Huge corporations are so hard for cross-platform development while Facebook, Google, Microsoft et alia could just spawn as many developer for a new platform as they can. I know that management is trying to cut back on every single penny, but is financing React Native really that much cheaper than just writing that tiny amount of code for each platform that will call into that single native library/web API used everywhere? Especially when you have to have a native dev either way because bugs will happen that will need platform-specific knowledge as well.

Because I can honestly understand going cross-platform by a small startup that can’t finance n*numOfPlatforms devs, but for Slack and the like it makes zero sense to me.

Re: Tauri – Electron alternative written in Rust

#384

Post by kaba0 »

Karunamon wrote: post #256
thawkins wrote: post #255

Earlier quoted context omitted.

what's the point of having a bunch of ram sitting around doing nothing, I would rather have a system that had zero free ram but managed its address space well, so that changing ram usage was painless. why pay good money to have hardware sitting idle?.

The same reason I refill my car's gas tank long before it hits zero; low/no resource problems range from irritating to catastrophic. Unused RAM isn't wasted, it's headroom.

But you OS doesn’t have to find a petrol station it may not even be able to reach — it can just swap to SSD or the best - swap to RAM itself by compressing pages (zram on linux and mac does it as well). Empty RAM is seriously wasted unless it is some embedded system where you are managing memory and need some strange latency requirements.

Re: Tauri – Electron alternative written in Rust

#385

Post by kaba0 »

Karunamon wrote: post #307
staticassertion wrote: post #294

Earlier quoted context omitted.

> 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 p…

>Only if you're constantly swapping in and out of swap. Which, in the experience I just gave, is what's happening. System memory at some high 90s percent utilization, swap usage creeping up, kswapd with a ton of CPU usage, and worst of all, UI chugging . If it wasn't 'actual' memory usage, why does dropping caches, instantly freeing up some amount of memory, restore responsiveness? I've tried operating swapless befor…

I recommend using zram. It is a life changer for my 8GB laptop. I seriously never had trashing ever since.

Re: Tauri – Electron alternative written in Rust

#386

Post by kaba0 »

mehdix wrote: post #194
mysterydip wrote: post #104

Earlier quoted context omitted.

Back in the day people coded lightweight because it wouldn't run otherwise, and speed mattered in single core sub-GHz CPUs. We don't have that same constraint today, how do we get people to write more efficient code?

Environment should be the new constraint. Inefficient apps collectively consume energy that otherwise would have been saved and therefore contribute to global warming.

Will you also wipe out every old-generation CPU in usage as well? Because a CPU using 4x the energy compared to a modern mobile one will be much more detrimental to the environment than that application running for 2 hours using up 10% more energy.

Re: Tauri – Electron alternative written in Rust

#387

Post by account-5 »

c-smile wrote: post #365
parhamn wrote: post #96

Earlier quoted context omitted.

This is a great point. I think last I measured a basic electron browser/webview is about ~20-36mb which is not far from an about:blank chrome tab. The 300mb+ memory usage you see is mostly the javascript from the apps themselves. Either way, I'm glad more people are in the space!

According to Tauri's documentation ( https://github.com/tauri-apps/tauri ) minimal app: Tauri Electron Memory Consumption Linux 180 MB 462 MB Note Tauri is full fledged Client/Server with WebView (client) running in separate process with RPC between UI process and Rust code (Server). For the comparison: Standalone Sciter (scapp.exe, https://github.com/c-smile/sciter-js-sdk/tree/main/bin ) takes ~8 MB of RAM (with min…

I was going to ask how this compared to Scoter, thanks.

Re: Tauri – Electron alternative written in Rust

#388

Post by dbrgn »

jitl wrote: post #221
skinkestek wrote: post #117

Earlier quoted context omitted.

Then do as I: develop in Firefox and if it works there (and isn't a PWA where maybe you get in trouble with Safari?) then it works everywhere. Less testing, less bugs. Whats not to like? Contrast to Chrome first developers who often get caught by cross browsers incompatibilities just like they did back in the days when they were IE first developers : )

There’s plenty of weird cruft in Firefox’s ~30 year old codebase that causes bugs and unspecified behavior. For example, Firefox’s ContentEditable code deletes things “backwards” compared to all other browsers and operating systems (bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1735608 ) - this behavior isn’t standardized in any spec, and Firefox is different from other browsers. There are plenty of gotchas…

Developing UI components based on ContentEditable is trial and error, with a lot of code held together by cross-browser integration tests where you always have to pray that a browser upgrade doesn't brake something new in a subtle and surprising way...

1/5, would not recommend. (But sometimes there's no way around it.)

Re: Tauri – Electron alternative written in Rust

#389

Post by Karunamon »

kaba0 wrote: post #384
Karunamon wrote: post #256

Earlier quoted context omitted.

The same reason I refill my car's gas tank long before it hits zero; low/no resource problems range from irritating to catastrophic. Unused RAM isn't wasted, it's headroom.

But you OS doesn’t have to find a petrol station it may not even be able to reach — it can just swap to SSD or the best - swap to RAM itself by compressing pages (zram on linux and mac does it as well). Empty RAM is seriously wasted unless it is some embedded system where you are managing memory and need some strange latency requirements.

As described below, that's what's supposed to happen, but the default kernel configuration in mainstream distros will happily hold onto caches while swapping so hard to be unusable, or worse, loosing the OOM killer to wreak havoc on my workspace. This is unacceptable, and this is why I want headroom.

At the end of the day, if my system wildly misbehaves under high memory pressure, and forcing the pressure down resolves the misbehavior (or keeping a certain amount of headroom prevents it from happening outright), "linux ate my ram" is an accurate description of what happened and no amount of tut-tutting telling me that it doesn't work the way I just got done seeing it work changes that.

I'll give zram a try, but the problem here is poor usage of memory (both in priority and badly-behaved bloatware), not quantity of memory available. I'm not a kernel developer, I shouldn't have to dork around with these kinds of knobs to get sane behavior.

Post reply on HN