Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Slint
Discontinued Slint is a toolkit to efficiently develop fluid graphical user interfaces for any display: embedded devices and desktop applications. We support multiple programming languages, such as Rust, C++ or JavaScript. [Moved to: https://github.com/slint-ui/slint]
-
webview
Tiny cross-platform webview library for C/C++. Uses WebKit (GTK/Cocoa) and Edge WebView2 (Windows).
-
tauri-vs-electron
Discontinued A comparison of the two frameworks: is Tauri a better choice than electron in 2021?
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
Yes, but this is my point.
https://github.com/tauri-apps/tauri/discussions/3162
> FabianLars, 3 hours ago, Collaborator
> ...for example my somewhat simple app uses ~120MB
> But only ~5MB is the actual tauri/rust process, the rest is WebView2.
So, if 60MB is a large download, surely a simple app using 120MB of ram is pretty outrageous too?
> There is no reason why hello world UI should be 60MB.
Absolutely, but you can't have everything. Fast. Small. Doesn't use any memory. Easy to develop for. Free.
You can't have them all. So... the question isn't "is 60MB ok?"
The question is: What do you care about the most? Is it really the download size?
It's not the download size for me.
I chose Electron for the app I was building because it would make sure the app I create (1 code base with Angular) would perform exactly the same way on Mac, Windows, and Linux. It required virtually no learning of anything new (just look up some Electron API like "minimize window") and I was done.
https://videohubapp.com/ & https://github.com/whyboris/Video-Hub-App
As a single developer, I was able to get an app out in a few months and have been improving it for 4 years now. I love it (enough to create a Renamer app too: https://yboris.dev/renamer/ ).
Note Tauri is full fledged Client/Server with WebView (client) is 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 minimal Cairo and GDI backends).
That's 20 times less than even Tauri.
WebView based solutions are not suitable for applets - small portable desktop applications.
People are doing that too. https://sixtyfps.io/ is basically a Qt clone in Rust, actually developed by previous Qt developers.
I mean… fair, but is the 60MB runtime the issue?
I really don’t care if my hello world UI is 60MB to download, I care that it consumes 1 GB of my precious ram to run.
How is running js with a rust backend any better than running js with a C++ backend?
I guess your “backend” is rust here, which is nice, but tell me this won’t sit there guzzling all the memory it can get it’s hands on for the UI?
Ie. really, do you get meaningful benefits from using this over say, literally just using https://github.com/webview/webview?
Sure, but Neutralino[1] already does this, it's just not Written in Rust™
[1] https://neutralino.js.org/
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
Proxy polyfill: assuming you are referring to this [0], since I haven't seen anything else like this, then I'll paste here what the readme says:
> The polyfill supports just a limited number of proxy 'traps'. It also works by calling seal on the object passed to Proxy. This means that the properties you want to proxy must be known at creation time.
i.e. that's not a polyfill. It's a polyfill for a subset of the thing, maybe that's useful for somebody, but it's useless for the use cases I had for Proxy so far.
Shipping an entire regex engine with your app: right, that's the only way to do something like that. Not that that's actually the same thing though, I can't just load this and use lookarounds as normal, i.e. it's not a polyfill.
For all practical purposes these features are not polyfillable. If your idea of a polyfill includes not actually polyfilling the entire thing or shipping an entire engine with your app then sure, anything is polyfillable.
[0]: https://github.com/GoogleChrome/proxy-polyfill
