For the scripted part of the application, you can allow 3rd party plugins. If you do, you should keep tabs on the success of different solutions in this Marketplace of Ideas. You should absorb (probably native code) the ideas with the broadest appeal. But don't forget to find a way to compensate the person whose plugin you just deprecated.
Anything you don't know will stick, should be done on the cheap, and in a problem space where porting is expensive, scripting seems to be the winning strategy. And some commentary from various game authors suggests to me that the scripting language also opens up some development parallelism that is harder to get with an API.
We get the majority of the features of jQuery in HTML 5, and I bristle a bit when people try to act like jQuery is dumb. jQuery won. We are here now because of jQuery. It is useful even if you never use it, maybe especially so.
It's not perfectly aligned with the use case, and those billions have not been efficiently spent due to competing interests and design-by-comittee, but you're going to have a really hard time matching that investment.
I know very little about this but I assumed one advantage to doing it this way would be that browsers have to access the same web and thus conform to some kind of web standards, making your cross-platform core achievable. What else could you reliably expect to be on a Windows/Linux/MacOS install with enough shared DNA or similar feature set to build your engine?
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.
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.
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.
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.
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.
I'm not arguing the utility of what your describing, just pointing out its not a new concept...
Anyway Qt is reasonably close as well, but with a compile per platform.
You could take this to the extreme and have every program run in a "pure" fashion per default (i.e. no inputs other than command line args - no outputs other than the exit status).
So I don't think you have any real alternatives until there's other technologies on the web or wasm can do everything.
If the web on iOS wasn't such a garbage fire, we could use React directly
If we agree that this is a useful approach to take for developing cross-platform applications, and I think it is for most, are web technologies the best way to achieve this or is there a better alternative?
Web tech has the advantage that when you don't have that "game engine" you can still run in a browser, but with these engines getting better, more storage, more use of app stores, and the fact that these apps are very much that, apps, and not publicly indexable web content, maybe this isn't a useful advantage anymore? Web tech also brings a number of disadvantages, such as a different security model and unnecessary legacy compatibility that holds back modernisation.