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

61–70 of 107 posts

Re: Tauri vs. Electron – Real world application

#61

Post by atwood22 »

bobblywobbles wrote: post #57

> #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 Ap…

It's _possible_ to build a secure Electron app, but it's also very easy to build an insecure Electron app. Even if you follow best practices regarding context isolation, it's very easy to introduce a subtle security issue like

    contextBridge.exposeInMainWorld('myAPI', {
      send: ipcRenderer.send
    })

Re: Tauri vs. Electron – Real world application

#62

Post by pornel »

jahewson wrote: post #59
pornel wrote: post #40

Earlier quoted context omitted.

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.

CSS evolves and there’s always some new funky selector or effect coming, but the whole point is that you don’t need to follow this year’s latest hotness. If you slap rounded corners and box-shadow (very old by now) you have 90% of what Apple calls design lately. For Windows “metro” you don’t even need rounded corners :)

Re: Tauri vs. Electron – Real world application

#63

Post by frutiger »

bobblywobbles wrote: post #57

> #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 Ap…

This is a weird claim anyway.

If you're loading first-party content into the view, then it's no less secure than running, e.g. a Node.js script (or Python, Ruby, C++ program, Rust program, etc.) as the current user. A program you downloaded being able to do things it's supposed to do is generally a feature, not a bug.

If you are loading third-party content, then sure, it's a completely different ball game.

Re: Tauri vs. Electron – Real world application

#64

Post by Kye »

BiteCode_dev wrote: post #32
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…

If you only provide a desktop app yes. If you also provide a web app, then the work needs to be done anyway.

Someone somewhere has already figured out how to run Electron through WASM.

Re: Tauri vs. Electron – Real world application

#65

Post by RussianCow »

pornel wrote: post #62
jahewson wrote: post #59

Earlier quoted context omitted.

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

CSS evolves and there’s always some new funky selector or effect coming, but the whole point is that you don’t need to follow this year’s latest hotness. If you slap rounded corners and box-shadow (very old by now) you have 90% of what Apple calls design lately. For Windows “metro” you don’t even need rounded corners :)

> but the whole point is that you don’t need to follow this year’s latest hotness

You might not have a choice. Sometimes even seemingly trivial APIs/features like SVG, flexbox, or audio/video behave slightly differently in different browsers, and it's easy to sink a lot of time into debugging these differences. I'm not saying the effort isn't ever worth it, and it's certainly better now than it ever was in the past, but I think you're underestimating the amount of work it takes to properly support a complex web app across all modern browsers.

With that said, if you're just using web technologies to throw together a UI to slap on your native app that does all the heavy lifting, then sure, maybe using something like Tauri is worth it. Even then, it might not be worth the QA burden of having to test all UI changes against every supported platform, and then the support burden of getting platform-specific bug reports.

Re: Tauri vs. Electron – Real world application

#66

Post by RussianCow »

noselasd wrote: post #56
maleldil wrote: post #43

Earlier quoted context omitted.

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.

It depends on how big your app is. The problem with Electron is that it bundles its own installation of Chromium, so if you have 5 Electron apps, you have 5 instances of Chromium taking up memory. With something like Tauri, the system web view is used, which is likely already loaded into memory, so the marginal memory usage of each additional application is very small.

A big enough application will dwarf Chromium's memory usage with its own, but for smaller apps, the cost of running your own Chromium instance will dominate your app's memory overhead.

Re: Tauri vs. Electron – Real world application

#67

Post by ripley12 »

orthecreedence wrote: post #44
saidinesh5 wrote: post #25

Earlier quoted context omitted.

Mold linker cut down a lot of the build time when we were writing a tauri app, but the build times were still .. not my favorite.

I know there's probably docs somewhere, but what was the process to integrate mold into your build chain? Is it involved or fairly easy? I just heard of this for the first time and wondering if it could be useful to cut down build times in all my rust libs/apps... EDIT: found this: https://www.reddit.com/r/rust/comments/rhcnzt/mold_a_modern_...

It’s trivial, check the README on Mold’a GitHub repo.

Re: Tauri vs. Electron – Real world application

#69

Post by autoconfig »

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…

Same here. Depending on the type of application being built, this can be a huge downside. E.g., if you want to store data locally using IndexedDB getting it to work properly on Safari (and to some extent Firefox) can be a soul destroying experience. See here for some examples: https://gist.github.com/pesterhazy/4de96193af89a6dd5ce682ce2...

Unless I'm building an app that also needs to work on the web, I'm choosing Electron.

Re: Tauri vs. Electron – Real world application

#70

Post by junon »

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.

I agree with your last point, no, sorry, reverse engineering machine code back to actual, re-compilable source is not at all straightforward. Hex-rays has been trying to do this for ages and still doesn't get things right
Post reply on HN