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

Tauri vs. Electron – Real world application

levminer.com

Post reply on HN
Print view View original

51–60 of 107 posts

Re: Tauri vs. Electron – Real world application

#51

Post by orthecreedence »

typon wrote: post #50

Calling this a "real world application" is a big stretch imo...Javascript's problems really come to the forefront when implementing complex logic in the backend - Rust's excellent type system helps a lot with that. However, if you have an app that has a lot of interactivity, using the web_sys API is a huge pain that basically caused me to end development on my side project. Working with DOM APIs in Javascript is so m…

I'm in a sweet spot for something like Tauri: I have an app that does a lot of cryptography and dealing with binary data in browserland is horrible. Embedding rust and leaning on it for the business logic and crypto stuff while only relegating the UI to html/javascript has been a huge success for me.

I think the rust frontend ecosystem has a long way to go before it can really compete with javascript and the many existing frontend frameworks.

Re: Tauri vs. Electron – Real world application

#52

Post by jupp0r »

"The app is compiled to a binary, which means you have to be an expert at reverse engineering to be able to de-compile the app."

It just means that nobody has written automated tooling to do this. The procedure is super easy and the implication that there is any security benefit to the way Tauri bundling works is fundamentally flawed.

Re: Tauri vs. Electron – Real world application

#53

Post by intelVISA »

jupp0r wrote: post #52

"The app is compiled to a binary, which means you have to be an expert at reverse engineering to be able to de-compile the app." It just means that nobody has written automated tooling to do this. The procedure is super easy and the implication that there is any security benefit to the way Tauri bundling works is fundamentally flawed.

To be fair it's hard to understand what a "jump not equal" does if the numbers on FizzBuzz are accurate.

Re: Tauri vs. Electron – Real world application

#54

Post by WorldMaker »

eropple wrote: post #46
WorldMaker wrote: post #42

Earlier quoted context omitted.

But that's an Apple problem, not a "you" problem in that case. In Electron the security burden for tracking Chromium CVEs and sending updates out is entirely yours, whereas with Tauri you outsource it. In Electron, Chromium CVEs are your CVEs. In Tauri, Safari CVEs remain Apple's CVEs and technically entirely outside the scope of your application bundle. The trade-off for "old macOS webviews" is that it's not your pr…

Your users don't care whose fault it is. Your app isn't working. You can choose to cut those users off, and that's totally an option...sometimes. Mac users are probably a little more tolerant of this than non-Mac users, because of the general upgrade treadmill, but whether you can get away with it is a question only you can answer for your app.

That's still a very different class of problem from a CVE break of a single-point-of-failure is the point. Someone decides to use your Electron app's old Chromium build and a known CVE in it as a target vector for infecting or remote controlling user's machines is a very different problem from "because we are using system webviews this small CSS/JS feature doesn't work in this version of macOS, please upgrade". Even if the user rightfully blames you the app developer for both issues and doesn't allow you to point fingers upstream, one is a severe security threat that can destroy entire brands and the other is "mere tarnish" on a brand. (I know which class of problem I'd rather deal with, given the choice here.)

Re: Tauri vs. Electron – Real world application

#55

Post by jupp0r »

"With Electron you have full access to Node APIs, so a hacker could easily exploit the very powerful Node APIs."

This is not true, `nodeIntegration` has been disabled by default years ago in Electron 5.0 [1]. The default in Electron 20 will be a sandboxed renderer process that can't even read files from disk [2]. Security in Electron is great if you follow their security guidelines [3].

[1] https://www.electronjs.org/docs/latest/breaking-changes#plan...

[2] https://www.electronjs.org/docs/latest/breaking-changes#plan...

[3] https://www.electronjs.org/docs/latest/tutorial/security

Re: Tauri vs. Electron – Real world application

#56

Post by noselasd »

maleldil wrote: post #43
hasperdi wrote: post #41

Earlier quoted context omitted.

You're implying that application written in Rust would not have no size, memory and security issues. That is of course not true.

Do you think it's unreasonable to assume that an app written in Rust will be smaller, use less memory and be safer than a similar app written in JavaScript?

The UI part of the app with its HTML/CSS/Javascript is normally the most the memory hungry part - there won't be a huge difference there between tauri and electron.

Re: Tauri vs. Electron – Real world application

#57

Post by bobblywobbles »

> #6 - Security "Tauri is very secure by default, on the other hand I can't say the same about Electron... With Electron you have full access to Node APIs, so a hacker could easily exploit the very powerful Node APIs."

It's fair to believe this, given there's so much material out on the web affirming the fact. I've written about this at length in other places; applications with Electron pre version 5 [0] (released April 2019) were not secure. It's entirely possible and easy to build a secure Electron app today. I started building a secure app Electron template in 2020 [1] (that I still maintain) to address this security issue. I've also written about a history of the framework [2] and steps to build your own Electron app with today's best practices [3].

[0] - https://github.com/electron/electron/releases/tag/v5.0.0 [1] - https://github.com/reZach/secure-electron-template [2] - https://www.debugandrelease.com/the-ultimate-electron-guide/ [3] - https://www.debugandrelease.com/creating-a-simple-electron-a...

Re: Tauri vs. Electron – Real world application

#59

Post by jahewson »

pornel wrote: post #40
keraf wrote: post #16

The 5th point in this article is what makes me end up using Electron most of the time. As much as I love Tauri (and Wails), WebView requires to make sure the application renders exactly the same across all platforms. Sure, Electron comes with its downsides like the article rightfully points out. But having a UI that renders and behaves exactly the same on all platforms (thanks to the version locked Chromium bundled i…

Is that really such a big deal? Browser engines these days aren't so bad, especially if all you need from them is basic CSS for the UI. You still have a fully-fledged native language underneath it, so you're not limited to what Web APIs can do.

There is no such thing as “basic CSS”. Of all things it’s the most wildly moving target I’ve ever encountered.

Re: Tauri vs. Electron – Real world application

#60

Post by Dr_ReD »

As I see it, the difference between the Tauri approach and Electron becomes visible when you have multiple apps running.

Each Electron app will load its own browser back-end in RAM, while all tauri apps will share the same runtime on disk and in RAM.

This makes for quite a big difference as the number of running apps grows.

Post reply on HN