[iudqnolq]

They use whatever is the system WebView on the platform you run the code on. On Windows that's the Edge engine, on MacOS it's Safari's engine, etc. Those are all some combination of C and C++.

See https://github.com/tauri-apps/wry

Edit: s/IE or Edge/Edge

[wffurr]

That seems to eliminate one of main advantages of electron, the consistent runtime environment.

If your html/css/is has to work correctly in EdgeHTML, Safari Webview, and Blink, you are limited to the lowest common denominator features.

Electron with Chromium has the largest feature set out of all of those.

[knubie]

I can’t speak for other developers but my app runs on electron and the web (because why not?), so I need to make sure my app works with those browsers as well.

A lot of the big electron apps I’m aware of are the same (slack, notion, discord, etc).

[iudqnolq]

Slack used to use a similar approach but gave up in part because platform webviews are more outdated than browsers on average.

[derefr]

Electron has two "sides" to it — a renderer process, and a NodeJS process, that communicate over IPC (where as far as the renderer is concerned, the NodeJS process is kind of like a very intrusive browser extension.)

AFAIK, if you're writing a greenfield Electron app, it's best to do as little as possible in the renderer side, and as much as possible in the Node.js side, because the Node.js side has things like native threads and mmap(2), and everything running within the Node.js process can share that state, but things on the renderer side have to use it through RPC.

I would assume that this project is similar, but with arbitrary Rust code in place of Node.js (is that right?)

In that case, it doesn't matter how featureful the renderer is, as you're just using it as a GUI framework with a declarative view-model format. Just like a XAML or QML, but it's HTML+CSS.

As such, idiomatically, you won't be using fancy browser APIs like threads or WebRTC within the renderer; instead, you'll be using native code on the "app side" and then passing the renderer data. The features of Tauri itself are "whatever native libraries you want to bring into your Rust binary." (Plus whatever conveniences it already builds in, of course.)

[flyingswift]

This is actually untrue, you want to do as much as possible in the renderer process. The main NodeJS process is responsible for all user interaction, including mouse clicks and keyboard input. If you block the main process, the entire app will become unresponsive

[derefr]

But the main NodeJS process can spawn (regular POSIX) worker threads, just like any other GUI app’s main (event loop) process; and those worker threads can both 1. load native libraries and call into them, and 2. communicate just as directly with the renderer as the main thread can. The renderer, meanwhile, only gives you ServiceWorkers; and those can’t do anything natively. (Plus, they have all the same IPC overhead to the main renderer context that calling the renderer from Node does.)

Think of it like this: let’s say you’re creating an Electron equivalent to Mathematica. You have a big native blob of maths evaluation code. Where are you going to run it — in the renderer (as Emscripten WASM) or in a worker thread of the native app (as a native static library or DLL)?

Or let’s say you’re doing an Electron BitTorrent client. Where are you going to handle the network connections and do the file management and... basically everything the app does? Well, in this case, you have no real option: the renderer can’t open raw TCP sockets. You’ve got to do it native. (But it would have been the better choice anyway, for IOPS reasons—localStorage + virtualized attachment downloads don’t buy you very much disk concurrency.)

A less clear-cut case is a game engine. The answer there depends on whether you can get a handle to the renderer’s Canvas from your native code. If so, then the choice is obvious: native game engine, draw to renderer’s canvas. If not, it might still be more CPU efficient to go native: you might be able to approximate that over RPC if your game has a bandwidth-efficient wire protocol representation of its render command stream (as e.g. most 2D tile based games do.) Only if neither of these work would putting the game engine into the renderer be optimal.

[parker-codes]

For Windows it will actually install Webview2 if it's not there already so it's not running on deprecated IE.

https://github.com/tauri-apps/wry#windows

[ksec]

So basically on Windows it will use Edge. The idea is good, but this is not the first time someone try this. At the end it is all about testing, tools that needs to make 100% ( not 99% or 99.99% ) sure functions and rendering on all platform are intended as it is.

[iudqnolq]

Good to know. Still awful on MacOS, and you'd presumably need to check distro by distro for Linux.

[Thaxll]

So you need to make sure your code works on 3 different platform eventhough you're using a tool that's supposed to fix that problem in the first place?

I don't know the extend of WebView in Electron is it something common?

[nklayman]

A ton of time and resources have been put into making web apps work across multiple rendering engines. These days, it can be difficult to have something break on one platform if you are using a modern development stack. The webview engines that Tauri uses are all quite modern, see https://github.com/tauri-apps/wry/discussions/202 for more details.

[iudqnolq]

Worse, it needs to run on every version on every os. Windows 10 has an evergreen webview, but on Mac for compatibility reasons the webview is only updated with a new OS release.

Edit: This is not something you run into with electron. It's the reason electron apps are so big, they bundle the whole browser engine.