Any rich-internet or multi-media framework?

Is there a single framework with full API for developing front-end apps in Rust? For example, equivalents of Microsoft Silverlight, Adobe AIR and so on.

I want something that doesn't use the web browser.

What kind of app do you want to develop? 2D/3D game? A video editor? For desktop or mobile?

When you say "doesn't use the web browser", would you be willing to write part of the app in HTML/JS and then package your code into a native desktop or mobile app?

Without knowing more details it's hard to make a recommendation.

Two pages you might be interested in for the state of GUI and game development in Rust:

I haven't heard the term rich-internet framework ever and had to search it on the internet. As expected, Wikipedia tells me this:

With the deprecation of browser plugin interfaces and transition to standard HTML5 technologies, rich web applications were replaced with JavaScript web applications, including single-page applications and progressive web applications.

I think people nowadays prefer different technologies, so it might be hard to find what you are looking for.


Yep, a video editor. The framework doesn't need to cover e.g. the FFMPEG library.

No, I'd like to avoid using a web view in the app.

I'm aware of, but it only lists decentralized/disconnected libraries for use in the project.

To clarify more, I think that the web (HTML5 technologies) is lacking file system API to access files that ship within a native app. There is an origin private file system API, but that's just for data storage.

So, thus, I'm not very interested in using a web view (which could be a framework in general).

Installation files aren't the files exactly located in the same directory as the executable. It depends on the OS and how the app is installed.

Adobe AIR supports app: URLs in file system which allows to access installation files.

For a video editor I probably won't need what I referred above ("access installation files"), but I might create other projects that need it.

There are workarounds for that. For example, the VS Code editor is essentially a web view and it does a lot of filesystem access using external processes.

The Tauri framework, which has been getting a lot of publicity lately, lets you build something with all the capabilities of VS Code using JS for the user interface, and Rust or other languages for the "backend". If you want to minimize your use of JS, you can also compile Rust code to WebAssembly and run it in the browser. There are pros and cons to doing this of course.

I guess you would have to weigh up how important the following factors, among others, are to you:

  1. Cross-platform support (Win, Mac, Linux, etc)
  2. Programming language (pure Rust? Rust/other language hybrid)
  3. Feature set (are you working with huge videos? Are you providing very sophisticated editing features?)

Yeah, webview-based apps are not web browsers. They are not beholden to rules like CORS. In fact, they can (and almost always do) execute native code in some form. Especially for things like accessing resources in the host OS (file system, threads, sockets, USB devices, etc). So, I don't believe that "lacking file system API" is a compelling argument against using web tech to create native apps.

I have other reasons for not using webview, personally. Amongst them is the issue that the webview is basically its own OS (see the inner-platform effect) and I dislike the overhead. Especially because it doesn't make things substantially easier or more maintainable [1]. But this is just my personal preference. If you don't mind the overhead - nix that, if your users don't mind the overhead - then it really doesn't matter whether a webview powers the app or not.

Ultimately, I don't think there is an "all-in-one" framework that covers all of your use cases [2]. Gluing together disparate libraries is how all applications come together, anyway.

  1. Maintainability of these apps suffers from the dozens of additional frontend packages they inevitably need to depend on. ↩︎

  2. And I'm generally skeptical of projects that make this claim, anyway, because they just become another inner platform. ↩︎