Live data from Hacker News

Tauri vs. Electron – Real world application

levminer.com

81–90 of 107 posts

Re: Tauri vs. Electron – Real world application

#81
Tauri:

   Test CPU RAM GPU
   Idle 1% ~ 80MB 0%
For the comparison, Sciter:

   Idle 0.01% ~ 40MB 0%
With startup time (minimal hello world) 200ms

As of memory consumption: the bulk amount is in graphics backend - Direct2D in case of Sciter. I believe the same cap applies to Tauri and Electron.

Re: Tauri vs. Electron – Real world application

#82

Earlier quoted context omitted.

Those are shared but... Tauri is using less than 80 megs, Electron is using 143 for the main process alone, so it doesn't really make a difference. Tauri is way lighter

assuming you use chrome, electron will reuse the chromium libraries, so the net increase on memory is not that large. with Tauri, it will have to spin a new set of (memory hungry) browser libraries(i.e. libwebkit2gtk on linux, similar stuff on Mac and Windows) that are all new memory usage on top of chrome(nothing to share), not to mention the libraries Tauri uses are not as "modern" as Chromium on html5/css/js/webap…

No, Electron cannot reuse Chromium libraries. Every Electron app bundles and loads its own copy of Chromium; it’s bound to that specific version and can’t share it with any other app. Also, Chrome isn’t Chromium; it may be compiled from the same code, but that doesn’t allow the OS to substitute one for the other.

Re: Tauri vs. Electron – Real world application

#83

Earlier quoted context omitted.

assuming you use chrome, electron will reuse the chromium libraries, so the net increase on memory is not that large. with Tauri, it will have to spin a new set of (memory hungry) browser libraries(i.e. libwebkit2gtk on linux, similar stuff on Mac and Windows) that are all new memory usage on top of chrome(nothing to share), not to mention the libraries Tauri uses are not as "modern" as Chromium on html5/css/js/webap…

No, Electron cannot reuse Chromium libraries. Every Electron app bundles and loads its own copy of Chromium; it’s bound to that specific version and can’t share it with any other app. Also, Chrome isn’t Chromium; it may be compiled from the same code, but that doesn’t allow the OS to substitute one for the other.

you're correct, the chromium part is indeed statically linked, my only argument will be that html/css/js/webapi support, where chromium is more complete than whatever Tauri uses on each platform. for that alone, I will bear with more memory/cpu. plus there are more developers good at js than Rust.

Re: Tauri vs. Electron – Real world application

#84

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

    $ cat ~/.cargo/config.toml                                                                                                                                                                                                                                                                                                                                               
    [target.x86_64-unknown-linux-gnu]
    linker = "/usr/bin/clang"
    rustflags = ["-C", "link-arg=--ld-path=/usr/bin/mold"]

Re: Tauri vs. Electron – Real world application

#85
> Shipping an app without auto update in 2022 is a no go. If your user has to manually download every update I don't think they are going to be happy.

Honestly, in certain crowds the opposite is true. Having to install updates for software that is for all purposes feature complete is incredibly annoying, if you don't need an actual bug fix for something that impacts your workflow.

Sure, there can be security concerns, like in software that's used to sign documents and whatnot, but for most local software for things like content creation, updates are a nuisance a lot of the time.

Consider something like LibreOffice - if things work for me, I don't want some update that could cause a flawed re-install to happen behind the scenes and lose some of my preferences, file history, or mess with anything else in my workflow along the way. I am okay with manually installing the latest version once per year or something.

Re: Tauri vs. Electron – Real world application

#86
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 El…

And here you have proof for part of the reason Chrome dominates the web now.

No matter the values and benefits, testing on another browser is to much of a hassle for most web devs.

Re: Tauri vs. Electron – Real world application

#87
> Shipping an app without auto update in 2022 is a no go.

I don't agree with this at all. Shipping an OS with no auto-update mechanism for apps is a no-go. Applications don't need to re-implement such basic functionality.

Imagine if every single desktop application had to re-implement this. The burden on developers would be huge, applications would be enormous, and the system would be a mess to manage or use.

Re: Tauri vs. Electron – Real world application

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

> As much as I love Tauri (and Wails), WebView requires to make sure the application renders exactly the same across all platforms.

I think having an alternative to the Google-centric monoculture that is Chromium is actually one of Tauri's big points.

Re: Tauri vs. Electron – Real world application

#89
post #80

Earlier quoted context omitted.

and https://neutralino.js.org/ Their exciting part is > You can extend Neutralinojs with any programming language (via extensions IPC) and use Neutralinojs as a part of any source file (via child processes IPC). still: > Neutralinojs doesn't bundle Chromium and uses the existing web browser library in the operating system (Eg: gtk-webkit2 on Linux). Neutralinojs implements a WebSocket connection for native operations…

> You can extend Neutralinojs with any programming language (via extensions IPC) and use Neutralinojs as a part of any source file (via child processes IPC). I do not understand the second part of this sentence. What does it mean to use Neutralinojs as a part of any source file (via child processes IPC)?

See "Using Neutralinojs from your source files" here: https://neutralino.js.org/docs/how-to/extensions-overview/

Re: Tauri vs. Electron – Real world application

#90
post #9

One thing I don't see mentioned is the horror of shipping for Windows. You'll need Windows to have the Edge runtime, which means you have to bundle it or install it as an add-on. People will complain about this, especially IT people, because Edge runtime runs some kind of stupid background service all the time for no clear reason. It's also brittle since you will have to constantly keep your installer up to date with…

Man, there are a lot of incorrect statements in this. MS keeps the evergreen bootstrapper URL stable specifically so you can download it programmatically, it’s not fragile. And if you choose to ship the evergreen bootstrapper yourself, you don’t have to update it. The WebView2 runtime ships with Windows 11, major applications like Office, and they’re currently rolling it out to most Windows 10 installs.

The problem is enterprise environments where they tend to run stripped down locked down Windows installations and don't like to upgrade.

We used to use a native webview in an app and found that our app (packaged as MSI) would not install in a lot of enterprise environments because they don't allow secondary installers not signed by the same key as the primary installer. That means no bundling or side loading Edge. They would also require special security policy review to install Edge, making the whole thing really painful.

If you are only targeting personal end users a lot of what I said may not apply but it absolutely does apply in enterprise.

P.S. We did finally drop Windows 7 support a while back but we still get asked for it regularly. We get asked for Windows XP every now and then. Enterprise.

Post reply on HN