Tauri – Electron alternative written in Rust

As someone who uses Safari on Mac, I can say that compatibility issues are a big deal. Granted many of the issues are simply from sites checking for Chrome and telling everything else to f--- off. I've even seen a site fail to run on (chromium) Edge because it really wanted Chrome. However, real compatibility issues are a thing as well.

That said, I hate electron. I hate that I have to run 4-5 instances of chrome on my machine all day long for various different apps instead of the developer checking that their stuff works across the 3 main rendering engines.

I don't know about that, one data point: an ES2018 feature, regex lookarounds, is still not implemented in Safari. And the JS engine is the thing that's the most compatible across browsers, nowhere near the level of incompatibility of the rendering engine for example.

As a guy who started web development when IE6 was the dominant platform I cannot cherish "browser monoculture" enough.

.clearfix

It's much bigger than you think.

If I'm building an electron app, it's because I need native code running in nodejs/V8 as native addons, often in the render process, or I'm using bleeding edge APIs not available on Safari.

This type of framework is simply not an option.

Safari is missing features and has its own quirks so I wouldn't say that.

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 (because I <3 rust), 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?

I’ve always felt that engine inconsistencies in electron-alikes are a bit overblown, particularly now with the old IE-based webview out of the picture (modern Windows uses a Blink-based webview). They’re all capable of the basics, and the greatest inconsistencies will be found in newer features. Stick to a slightly older well supported set of features and you’ll be fine.

There are some significant differences between engines when it comes to things like local file access, but that’s what the native component of electron/tauri/etc is there for.

I'm not sure why downvoting is needed. What's said is true: on the web we already have to deal with different browsers and versions. It should be a fact of life for web developers. And things today are still infinitely better than back in the IE 6 days: many modern features work on all major targets. Why do people insist so much on engine consistency for "desktop web apps"?

Yeah, and large fraction of the dev appeal of Electron is that a concern that has haunted web development for a quarter of a century is completely out of the picture when you do Electron. You're not even concerned with possible differences between past, present and future versions of the engine because your code runs with exactly the version you bundled.

Sure, if your app is just a faux-native variant of something that is developed for the browser anyways nothing is lost, but if it's an offline first application that just happens to use web tech for UI the difference is huge.

Most cross compatibility issues have been resolved in browsers. Firefox and Chrome are pretty much at parity, Edge is chrome and Safari is the exception.

Web views are less standardized though and require more finesse.

Chrome is the new IE6, and guarantees cross platform compatibility everywhere it uses its own renderer though. (Basically !iOS.) It's a strong reason for choosing to Electron for your "native" app.

Everyone is basically using Chrome or Safari nowadays - so WebKit. Very little incompatibilities to consider compared to writing something that works on different WebView implementations

Sure, but Neutralino[1] already does this, it's just not Written in Rust™

[1] https://neutralino.js.org/

Arguably that's like observing that the same feature works differently in 2+ browsers and blaming web devs for it. It's the job of the browser people to make correct, or at least consistent, platforms.

While part of being a web dev unfortunately is also dealing with this you can't necessarily blame web devs when Safari breaks IndexedDB for the nth time, or when after using ES2018 features like regex lookarounds you discover that Safari still hasn't implemented them (which year are we in now, 2022?).

You may also discover that mobile and desktop browsers work differently in some aspects, not everybody even has the resources to test every single thing in 3+ desktop browsers (which may require at least 1 VM already if you are not developing on macOS, which I think might even be illegal to run in a non-mac hardware, bizarrely) and 3+ mobile browsers (which may require at least one physical device or a macOS VM for the iPhone, and another physical device or another VM for Android, and all these VMs aren't exactly lightweight).

Besides an Electron app doesn't necessarily have to run anywhere else, there's no point in checking compatibility with Gecko when your app never has to run there.

Does the Chrome engine, embedded within Electron, contain any Chrome features which one could legitimately call into question (such as sync)?

If not, what's wrong with it "spread[ing]" everywhere?

It's hardly lazy dev work. It's a pragmatic approach to developing cross platform apps quickly. Apps that, it might be added, don't have a horrendous UI, which is common with other frameworks.

>(no JS, or at least optional) IMO reply

At this point why not focus on some actual GUI toolokit, like write a Qt clone in Rust, for real world apps we don't need all the CSS and HTML crap, you need simple layout, GUI components and an option WebView you can embed in the app if needed. Probably there is no commercial interest to pay professional developers with real experience to implement this.

Tauri allows you to build apps that are pure rust - the js is optional and has multiple configurable integration models called 'patterns' that allow defining and constraining the engines includsd, the interfaces between them, and the tradeoff between binary size and distribution simplicity/robustness.

https://tauri.studio/en/docs/usage/patterns/about-patterns

Webkit not WebEngine. ( https://webkitgtk.org/ )

Wry is for desktop, but the grandparent is also targeting mobile.

Vanilla webviews is definitely possible on Windows with Webview2 https://docs.microsoft.com/en-us/microsoft-edge/webview2/ The problem though was compatibility since that webview might be based on old versions of Edge which used to be a much more outdated browser than Safari/Chrome. So far in 5 years of using Electron Windows never broke Electron except on a minor instance. Our Windows Electron app doesn't work on Windows 10 S. The problem might have became fixable by now but Windows S had so little marketshare that we never found time to fix that issue.

I mean MacOS, not Windows

Modern games have a shit-ton of assets in high quality. That takes up significant space no matter how you deal with it.

Electron generally isn't doing anything more interesting than what we did on Win98 with 8MB of ram for the entire system.

The meme is bad, but seeing it as text is even worse.

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

As a meta reply - it's quite funny to see this meme in textual form.

It's not just the developer experience, in fact that is probably lower on the priority than you would think. The entire business IME struggles to reason about a product, in the details, that is logically 1 product but physically N products by virtue of all the different target platforms and codebases required.

JS DX always seemed really quite bad whenever I looked. A constantly shifting landscape of frameworks and packages where nothing will stand for long before being eroded away.

> 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.

> in 2022 the developer experience is what matters the most to many software companies (yes, in many cases ahead of the customer experience).

Not working on iOS

> ... and in 2022 the developer experience is what matters the most to many software companies...

This is what happens when you keep lowering the bar, and more and more developers can do less and less.

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

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.

> 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.

While I agree that maintaining one codebase is preferable, the 'teams' part is a bit off.

No-one wants 'three teams building one product' which is why it almost always is far better to have one team with android, iOS, web and desktop mixed. Obviously if their mixed erpertises are around one codebase, that is even better.

> It makes perfect business sense to use electron.

In many cases, it should also make perfect business sense to use PWAs. I've heard Adobe has brought a significant part of the Photoshop and Illustrator functionality into their web apps.

WPF had the equivalent of "inspect element" 10 years ago. You don't need HTML for that, you just need good tooling.

The bits that face the user are an important part of, but only a part of, all the gears and wheels that make a computer programme useful

With all due respect, I think the web’s layouting (or lack of) is the most complicated out of any framework I have ever used (including qt, swing, javafx, winforms, wpf). I think the great majority of web devs would have trouble recreating something like bulma (regarding layouting) even without responsiveness — I definitely would have quite a bit of trouble doing that.

So if anything, we are just accustomed to the web’s way and other (saner) approaches look stranger for some reason (even though with some insane complexity js frameworks come back and mimic the two decade old frameworks here and there)

Can you explain more the part about native apps being hard to make? I mean, I can open Xcode, start a new project, hit run, and there's an app ready to go, with a simulator and everything. It has API's that allow safe access to OS-level resources. It has powerful multi-threading, built-in views that I can reuse (like collections), stack based browsing is native, etc... Also, the client is not broken by default (I.e. client apps in the browser are by default spyware, at a technical level).

All the weird tooling that exists around actually getting html + js + css to work like an app is an indication to the contrary. The constantly evolving ecosystems is an indication of reaching stability, not having yet achieved it.

I will say though that targeting different platforms is an issue, which is not the same thing as your claim. Yes, targeting all platforms is hard, but I don't think any one native app ecosystem is really any harder than web.

I do think there's a lot of survivor bias from people whose job it is to build apps with web technologies.

And to your point that "it won". I don't think anyone, even lay-people, like electron-based apps. It's just what they have to use because there is an infinite amount of web developers. However, I feel that it's a bit premature to call call something that's ubiquitous that everyone hates as "winning".

Also, the most used software as a matter of time on task would probably be excel, email clients, and web browsers. All of these are built natively. So with the exception of slack, and taking a broad view of the road that lies ahead, most of the stuff that's built on electron is sort of vapor in the grand scheme of things.

I think we can actually expect to see more and more native apps, due to power consumption requirements. I stopped using Chrome years ago due to its aggressive power/memory consumption and never actually really looked back.

Any way, sorry for the unnecessarily long response, but seriously what you're saying is very hyperbolic. We are literally just at the beginning of the absolute beginning in terms of what technology is going to look like. Things will be very different in 5 years and super different in 10-20 years.

Has the web won on mobile? No. In fact there was a time in which Cordova-like apps were getting very popular, but react-native and then Flutter, Kotlin and Swift have ended that. Or at least that's my impression. react-native is almost like the web still though, but the fact that people are doing react-native and not Cordova must mean something.

Meanwhile, 10 years ago the only ways to do desktop native apps were the old -- very good, but old, with that old feel -- technologies like GTK and so on. Now there are these other things I cited above, and more! It's a renaissance.

But isn't this the danger of evaluating something via simple example?

You can make fine websites with just a text editor (although I'd argue how easy CSS is to use) but as soon as it needs to be an app you need JS code, and suddenly the difference isn't so great. Infact, I'd probably find a traditional prog-lang easier to use in that case.

I think the real advantage of JS is the robustness of its sandbox & permission system, that's what really needs reproducing.

Oops: For the record, DomTerm is https://domterm.org, while bothner.org is (I believe) some unrelated German family. (My personal/family website is bothner.com.)

It cheerfully builds and runs on M1.

I do not really understand the lisence of this. In the repo it says its open source but on the website they ask for money?

no, but looks like it natively builds for m1 :)

According to Tauri's documentation (https://github.com/tauri-apps/tauri) minimal app:

                                    Tauri   Electron

    Memory Consumption Linux        180 MB  462 MB

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.

Operating systems should being pointing fingers at egregiously heavy apps.

It’s not perfect but the battery menu on macOS pointing out apps consuming a lot of energy has inspired a good amount of efficiency work for macOS ports of things because users see it and gripe at developers about it.

I would like to see that taken a step further. Something like the system showing a notification banner saying something to the effect of, “BadApp is consuming excessive amounts of energy. Quitting it will increase your battery life by approximately 3 hours and 15 minutes.” I believe quantifying the loss that the user is suffering as a result of the developer’s laziness will go a long way to inspire displeasure in users, who will then apply pressure on developers to fix it and opens up space for competitors who sell themselves with better efficiency.

You can't. Humans are lazy and working within constraints requires discipline and effort. Waste expands to fill the available space. The only thing that made old software efficient is that it wouldn't run if it wasn't efficient enough. And BTW there was crappy old software that made your computer chug back then too, it just looks better now because computers have gotten so much faster that apps can be a lot sloppier before users notice.

People still write efficient code where it counts. There is a trade off between development velocity vs efficiency & reliability. In most consumer software the advantages of building and shipping more frequently largely outweigh saving on compute, memory, or disk, which is historically cheap.

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.

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

Get them to stop pushing developer productivity above everything else.

You look for places where a potential customer base is unhappy about the slowness, and see if provides an opportunity to compete.

There's little else until/unless people see enough well performing applications that they start complaining or move away from the slow ones.

People around here seem to really struggle with the miracle that is getting into soft dev from nothing and then actually being employable in the capitalist sense after 6 or so month.

Of course it's a trade off! We enabled this miracle by training people that have a very focused, narrow understanding of not even a field but a particular tech. Electron is basically the perfect fit for this type of education. It enables someone to build something where previously they could build nothing. It makes getting from 0 to 1 that much easier.

From a business standpoint, it's simply smart to be wasteful with resources that are abundant (average computing power on personal devices), when it helps you save on resources that are not (dev time). But of course, there is much not to like about the side effects.

I would distribute a web app as a website, not as an Electron app.

That does sound really nice - would love that with Tauri.

I've never used Typescript, so at the moment I just have the pain of untyped structures in JS-land (and making sure I get it right passing back in to Rust-land) - but, at least as far as I know, if I did use TS I'd just suffer from manually duplicating data structures instead.

(I suppose ultimately I intend to do that, it's just so imperfect anyway that I haven't bothered yet.)

Wails works on Linux, has been for years but they decided to delay the Linux version for the latest release for some reason.