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