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

261–270 of 435 posts

Re: Tauri – Electron alternative written in Rust

#261

Post by austincheney »

oceankid wrote: post #223
austincheney wrote: post #59

Earlier quoted context omitted.

I have written a full OS like GUI in JS proving that it can be tiny and memory efficient. The GUI part of the application is about 2k loc across two JS files plus CSS and includes full file system display and navigation. It’s all vanilla JS and static DOM methods so it’s as fast and memory efficient as the browser allows. It’s amazing how fast the browser can be for this (and tiny) when you aren’t using querySelector…

Curious, what do you write that is 'OS like GUI' that doesn't require querySelectors, DOM and event handlers? How do you handle the nuances of GUI and input handling?

Content is dynamically generated in response to user interactions. For example a user clicks a button to navigate to a parent directory the new directory contents are fetched and populated into DOM artifacts using a function which recognizes the returned object as a microservice instance.

Instead of querySelectors I use things like getElementById, getElementsByClassName, getElementsByTagName, and some custom DOM navigation utilities I wrote for this application like getAncestor, getModalsByModalType, getNodesByNodeType, and so forth.

You don't need any kind of framework or fancy wiring to work with events. You always know what you are working with from within the event handler, because event handlers receive an implicit event object as their first argument. From that there is event.target which returns the element the handler is assigned to or event.currentTarget which returns the element the user interacted with that fired the event after bubbling.

State management is also just as easy.

Re: Tauri – Electron alternative written in Rust

#262

Post by staticassertion »

Karunamon wrote: post #245
staticassertion wrote: post #225

Earlier quoted context omitted.

Who says using a ton of RAM isn't efficient? Unless your system OOMs what's the downside of having a bunch of allocated memory? Especially if it isn't even paged in.

I do, because your program isn't the only thing running on my system . Low free RAM means paging, and generalized slowdowns when something else RAM-hungry, like a game or a web browser, is invoked. Memory is a limited resource to be used judiciously, not an all-you-can-eat buffet.

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.

Re: Tauri – Electron alternative written in Rust

#263

Post by staticassertion »

mysterydip wrote: post #229
staticassertion wrote: post #225

Earlier quoted context omitted.

Who says using a ton of RAM isn't efficient? Unless your system OOMs what's the downside of having a bunch of allocated memory? Especially if it isn't even paged in.

The things you pointed out are the problem. On RAM-heavy machines you're right, it's not noticeable and can even be a performance boost. The problem is that same app is run on machines with all kinds of capacities and system loads.

Phones have gigabytes of RAM. It's a relatively niche situation where someone is running Chrome on Besides, memory usage is hard to measure. Lots of memory may never get paged in.

Re: Tauri – Electron alternative written in Rust

#264

Post by munro »

I used this a bit, it was really great. Writing a Rust backend & exposing it to TypeScript was really slick!

There was one issue I ran into that made me think about jumping to Electron mid project, but I can't remember what it was now, but I think it was something like making my app bleed the entire MacOS window while still being moveable.

The other downside is you're going to be tempted to go down the rabbit hole and do everything in Rust. [1]

[1] https://github.com/Submersible/sycamore-mac

Re: Tauri – Electron alternative written in Rust

#265

Post by steveklabnik »

mysterydip wrote: post #254
SavantIdiot wrote: post #214

Earlier quoted context omitted.

Drake turning away: ElectronJS 0.06GB app Drake approving: Any modern game requiring 100GB of content

I'd love to see some electron apps that use 60MB of RAM. Can you share some examples?

Right now, the various Electron apps I have running:

1Password, 155mb

Discord, 441mb

Element: 38.7mb

Signal: 91mb

Slack: 46.2mb

A few higher but a couple that are lower...

Re: Tauri – Electron alternative written in Rust

#266

Post by giorgioz »

WolfOliver wrote: post #69
WolfOliver wrote: post #22

Earlier quoted context omitted.

would this work for Windows and Linux too?

I mean MacOS, not Windows

yes we already had a macOS published on the App Store for 2 years written as a thin Swift app with WKWebView: https://apps.apple.com/us/app/waiterio-restaurant-pos-system...

https://developer.apple.com/documentation/webkit/wkwebview

The app store reviewers will allow apps with only webview only if you are offering some feature that would not be possible to implement in the browser alone.

Re: Tauri – Electron alternative written in Rust

#267

Post by microtonal »

adwn wrote: post #250
AtlasBarfed wrote: post #207

Earlier quoted context omitted.

So efficient for you, but 1000x more resources everywhere it runs. I wonder if someone can quantify the carbon impact of Electron just from Slack.

> 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 a large net improvement in resource use for those who'd choose to install the iPadOS version. Unfortunately, they disallow iPadOS installs on macOS to force people to use the terrible Electron version.

[1] https://cancel.fm/ripcord/

[2] https://shrugs.app

[3] https://twitter.com/slackhq/status/931599784137363459?lang=e...

Re: Tauri – Electron alternative written in Rust

#268

Post by lijogdfljk »

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.

> I have a hard time understanding why platforms like electron are so popular.

For an example. I'm writing a FOSS app mainly for myself, but i am publishing it for everyone of course. I want to support Browsers, but also "Apps" in OSs. I'm on Linux, MacOS, Windows and iOS every day.

I do not, by a large margin, have the time to write my application in 3 or 4 different native UI toolkits. Furthermore, my application has a lot of text editing and rendering functionality, one i'd have to then reinvent in various UI toolkits, unless i used something that crossed all OSs above perfectly. Finally, my app has WASM plugins, similar to Obsidian.md, to allow the user to easily extend the application.

All together i will not, by a large margin, use anything Native. I barely have enough time _(don't, honestly lol)_ to write the app once - let alone supporting all the above platforms.

I'm targeting the web.

As an aside, i'm writing this in 100% Rust lol. No JS, because i prefer Rust.

Re: Tauri – Electron alternative written in Rust

#269

Post by [deleted] »

wolframhempel wrote: post #218
rebolek wrote: post #65

Earlier quoted context omitted.

> I really don’t care if my hello world UI is 60MB to download lot of people cares, they may have a slow connection, must pay per MB and so on. There is no reason why hello world UI should be 60MB.

Arguably both Slack and Spotify (and Visual Studio?) have reached significant scale with Electron apps - so at the end of the day it seems to be less of an issue for end consumers.

[deleted]

Re: Tauri – Electron alternative written in Rust

#270

Post by microtonal »

steveklabnik wrote: post #265
mysterydip wrote: post #254

Earlier quoted context omitted.

I'd love to see some electron apps that use 60MB of RAM. Can you share some examples?

Right now, the various Electron apps I have running: 1Password, 155mb Discord, 441mb Element: 38.7mb Signal: 91mb Slack: 46.2mb A few higher but a couple that are lower...

How are you measuring this? Slack on my Mac is 325 MiB on disk (probably because it is a universal binary). A freshly-started Slack uses 461MiB RAM for all it's processes (usually getting worse when it has been running for a while).
Post reply on HN