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

101–107 of 107 posts

Re: Tauri vs. Electron – Real world application

#101

Post by RussianCow »

mccorrinall wrote: post #78
RussianCow wrote: post #65

Earlier quoted context omitted.

> 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,…

Fyi you need to optimize for two browsers only: chromium (edge) is the webview on windows, and webkit is the webview on linux and macos. Anyway, I’m curious about the svg and flexbox issues you mentioned. I have not experienced any differences with those across systems and browsers.

> Fyi you need to optimize for two browsers only: chromium (edge) is the webview on windows, and webkit is the webview on linux and macos.

You're right, I keep forgetting that Microsoft has switched to Blink. It's still a pain if you're a Windows dev who needs to test on WebKit. Or is there an easy way to test that these days?

> I’m curious about the svg and flexbox issues you mentioned. I have not experienced any differences with those across systems and browsers.

To be fair, the differences I was thinking of were mostly between Gecko and Blink, so they're not really relevant to Blink vs WebKit. It's been many years since I've worked directly with SVGs, but I remember there being major differences between how different browser engines interpreted masks and some other features of SVG. I also think they scaled SVGs differently. The flexbox issue I'm thinking of had to do with how Gecko and Blink handled `height: 100%` inside a flexbox container that does not have a set height. I don't remember the exact difference, but I think Chrome assigned a height of 0 to the element, whereas Firefox greedily took up all of the available space, or something like that. Like I said, it's been a few years, so take all of that with a grain of salt. I just remember spending far too much time debugging those sorts of issues. :)

Re: Tauri vs. Electron – Real world application

#102

Post by RussianCow »

pornel wrote: post #94
RussianCow wrote: post #65

Earlier quoted context omitted.

> 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,…

I’ve been writing web apps professionally for lovely browsers like IE6, Android 3.0, and Blackberry. I know when CSS can be hard to get working. 2022 WebViews are a walk in the park.

Yes yes, I don't mean to complain. :) Web dev these days is definitely a breeze compared to the "old days". I just don't like when people assume that cross-browser testing is no longer necessary at all, because there are still differences, especially if you use any of the newer or more obscure APIs.

Re: Tauri vs. Electron – Real world application

#103

Post by schemescape »

I was expecting Tauri to be lightweight, but it appears to have 1200+ dependencies [1]. Does this mean that if you want to publish an app based on Tauri, you'll need to put those 1200+ copyright notices somewhere in your app?

Compared to Electron, this probably is actually an improvement, but I was kind of expecting Tauri to be a thin layer, ideally with an easy-to-add copyright notice (instead of "it is your responsibility to verify that you are complying with all upstream licenses" [1]).

[1] https://tauri.app/about/architecture/#license

Re: Tauri vs. Electron – Real world application

#104

Post by yencabulator »

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.

With Tauri, the backend with all the non-UI logic is Rust, so you can't just magically spit out source code from the binary. With Electron, the non-UI logic is NodeJS, so you can extract bundled Javascript. Bundled Javascript is much more obvious than machine code.

Re: Tauri vs. Electron – Real world application

#107

Post by greenhatman »

WorldMaker wrote: post #42
Klonoar wrote: post #29

Earlier quoted context omitted.

System webviews on macOS aren’t updated after a certain point, so Tauri is not necessarily always a win re: your final point.

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…

This actually makes me think Electron will be a lot easier to support. Because at least you'd be able to control which version of Chromium your app ships with. If you're using Tauri, you'll need to support all the different versions of WebView that are out there.
Post reply on HN