If we're building a new cross platform engine for these sorts of applications, then we get to define those standards.
Electron essentially "bootstrapped" a standard environment from things people were already familiar with, but my point is that this may not necessarily be the best way forward in the long term because the requirements on the web don't match the requirements of desktop apps anymore.
I think a new engine here would need to provide things like a UI model, filesystem access, OS interoperability (e.g. open/save dialogs, drag and drop), maybe sound/video, things like that. Web tech gives us these things, but they were all designed to run in browsers, not app-specific instances, so they have additional security/sandboxing requirements[1], they don't necessarily expose great multi-threading primitives because JS doesn't have any concept of these, and they do have a bunch of complexity around the notion that resources all used to be served up by a remote server, but are now embedded in your application.
[1]: This means that Slack on a Mac is sandboxed at the macOS level and the Blink/Chromium level. There's no need for the latter, and it adds complexity and performance overhead.
A new rendering engine is indeed one of the areas of the research at tauri. For now (and until 1.0 at least) we are sticking with the webview, because we want to have an alternative to electron that is safer and is well-known enough to be stable across platforms for the foreseeable future.
Regarding what an a new engine would have to provide, as a matter of fact, Tauri does offer cross-platform APIs for the filesystem, notifications, CLI, etc. These are all rust based, and available from JS.
I do have to disagree though, in one point, and that is that your single threading comment is only true in the webview. Technically, you have the entire strength of the underlying OS available to you from rust, and that is indeed where I recommend devs do all their heavy lifting. This is one of the benefits of using a polyglot system and an inherent security benefit.
Hi, thanks for your work, Tauri looks nice and it's good to have some competition for Electron.
My comment was quite "blue-sky", I'm not necessarily suggesting any of it for Tauri, but I think it's a useful thought experiment. If we weren't trying to be compatible with web tech (because I don't think we necessarily need to be), what would we change?
For example I think we'd probably not use JavaScript. JavaScript has improved a lot in the last 10 years, but it still has a lot of warts that are there explicitly for backwards compatibility with the web. If we're not trying to build for the web then we have so much more we can do.
While I think in Tauri pushing developers to put heavy lifting in Rust makes a lot of sense, similar to scripting a game engine we typically want to do this sort of thing as little as possible.
Without plugging away at a specific language, I'm a fan of https://github.com/hecrj/iced. It's native cross-platform (Linux/Windows/Mac) and compiles to wasm for web support. Native as in no web rendering - it renders its own widgets via wgpu - but that's the compromise for easy cross-platform support.
You use one interface for generic compatibility. This doesn't work for all cases, so you can also choose to add platform-specific code via conditional compilation to make sure that each platform's specifics are handled with intent, where you need to do so.
It's exactly what you're looking for. Early stages - file support is a little rusty (pun intended) - but it's coming along fast.
Does it have accessibility support? Generally the answer is 'no' for virtually all novel UI toolkits, especially immediate mode ones. I really love imgui but the lack of accessibility support means it can't be used on 'serious' projects that might ever be used by anyone visually impaired.
We're using it for an internal prototype. It's not a great story right now: https://github.com/hecrj/iced/issues/282. But it _does_ support basics for HTML, and ARIA could be added.
I disagree. If you follow the game engine analogy/thought experiment, I think there's much more that could be done.
There's a language, yes. There's also a runtime. There may be an interpreter depending on the language.
There's probably also a defined way of getting UI on to the screen in a platform independent way. There's probably also higher level concepts, maybe something that works a bit like a service worker, to use web terminology. There's likely to be a database of some sort, an app deployment system, software updates.
I'm not proposing a specific technology, but rather pointing out that there are a lot of parallels, and by realising that we're now using web technologies for shipping apps that aren't otherwise websites, maybe we could open up a lot of new potential solutions that might be even better.
Electron essentially "bootstrapped" a standard environment from things people were already familiar with, but my point is that this may not necessarily be the best way forward in the long term because the requirements on the web don't match the requirements of desktop apps anymore.
I think a new engine here would need to provide things like a UI model, filesystem access, OS interoperability (e.g. open/save dialogs, drag and drop), maybe sound/video, things like that. Web tech gives us these things, but they were all designed to run in browsers, not app-specific instances, so they have additional security/sandboxing requirements[1], they don't necessarily expose great multi-threading primitives because JS doesn't have any concept of these, and they do have a bunch of complexity around the notion that resources all used to be served up by a remote server, but are now embedded in your application.
[1]: This means that Slack on a Mac is sandboxed at the macOS level and the Blink/Chromium level. There's no need for the latter, and it adds complexity and performance overhead.