No question, just a small commendation. It pleases me that you acted appropriately to the criticism about Tauri not being native and removed this previously advertised claim.
Assuming you meant Deno, we used Node for the CLI because most web devs already have npm installed. We want the getting started process to be as simple as possible. Our Node CLI is just a wrapper really, as nearly all of the commands are actually implemented in Rust. You don't even need Node to build a Tauri app anymore. Node is not including in a shipped Tauri app, although we plan on supporting both Node and Deno as optional replacements for Rust in the future.
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++.
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).
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.)
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
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.
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.
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?
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.
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.
I see how the second part of my comment seemed like I'm asking for "Rust in the front-end", that was not my intention. My main point stands though, requiring Rust is not necessarily a "Con", it's in the "Pros" list for many people
It's off-topic, but it would be nice for someone to make a really good GUI toolkit for Rust. Something that integrates with system APIs for copy-paste and stuff like that.
I'm finishing this (no XUL tough), but the first impl(developer language) is in Swift. But the runtime the Swift access is pure C shims, so any other language can benefit from it.
If anyone is interested, it would be much easier to create those bindings to Rust. I'm super interested (and i would probably create a Rust SDK anyway) and there's a lot of other bonuses that neither Electron or Tauri can offer (as i target it not to be "just" a web-based app platform, but something that also had the soul of web browsers, by forming networks, addresses, etc).
If anyone is curious, there is more disclosure in another answer on this same thread.
i would love to give new all of those cool new languages that need a platform to thrive: Rust, Zig, Crystal, (and while not new) Python, a chance to have a 360 ecosystem, so we can stop being hostage of just Javascript being used.. and no, WebAssembly is definitely not it, as in the end it will give Javascript access to FFMPEG and the likes making it more prominent and ubiquitous