Support
Support
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PWAs, Wasm for desktop application development

alshdavid
New member
‎01-03-2026 03:50 PM
Status: New idea

Hi Firefox team!

I'm a web developer that has spent the last 4 years building native applications in Rust. The desktop application development landscape is very dire.

  • MacOS has AppKit with several crates offering limited bindings for Rust. These require a MacOS based device for compiling and are not really capable of tight desktop integration from Rust - at least not in a cross platform way
  • Windows has... actually who knows what Windows has. Win32? WinForms? WPF? WinUI? The examples on the Microsoft website for WinUI don't compile and the only GUI API that has Rust bindings is Win32 - which is practically impossible to use 
  • Linux has a slightly better desktop application support but it is hampered by ecosystem fragmentation. GTK/Adwaita or QT? Either choice will leave you with applications that are not idiomatic for the target desktop environment
  • The web is resource inefficient, and standard optimizations like multithreading are impractical to use and/or actually perform worse. 

It's my belief that this is the reason Electron and similar web-wrappers have taken over the desktop development landscape. The obvious issue there is that Electron apps frequently consume hundreds of megabytes of precious RAM (some applications use gigabytes), and despite the cost, are still sluggish.

This feature request is divided into two blocks;

Restore and fortify PWAs. 

Take the example of an offline web based

  • text editor
  • finance manager
  • image editor
  • video editor
  • audio editor
  • video player

Conventionally, documents would be stored in the cloud however what if I want to provide a traditional application that reads/writes to the disk, leaving backing up to the user.

I'd like to be able to create a mutli-tab PWA that has access to the filesystem (sandboxed) where the application can hold open handles to files and write/read.

This is _kind of possible_ with `SharedWorker` as a holder of said filehandles between multiple tabs, however it lacks certain sync APIs which are required by libraries like websql (should your web application store an SQL file)

WASM for high performance and memory efficient GUIs

Hypothetically, say my application uses no JavaScript - only css and wasm/rust. If the browser reads the html, understands that no JavaScript is required, and does not launch the JavaScript engine, that would unlock the ability to create very high performance, low memory applications (both conventional and PWA).

Assuming the wasi spec is implemented, a wasm binary could be embedded in the html with

<body>
  <script src="./main.wasm" type="application/wasi" allow-threads allow-filesystem></script>
</body>

Which automatically configures the ability to use threads and offers an FFI with dom operations. This would require no bindings/JavaScript thunking as the dom bindings would be provided by the browser. (This can be in the form of JavaScript WebAPI bindings included with the browser initially, eventually becoming a direct C++ -> wasm `import`).

example;

fn dom_document_create_element(doc: *mut c_void, tag: &str, ret: *mut c_void);
// The FFI API would be enormous, yes, but that's okay

This would allow web applications to be resource efficient and heavily multi-threaded (standard in native desktop/mobile development), while leveraging the ergonomics and cross platform support of the DOM/browser engine.

Contexts like service-worker and sharedworker could be done through html as well, where communication could be provided with message passing via a `fn document_get_element_by_id(&doc, "serviceworker")`

<body>
  <script 
    id="serviceworker" src="./service-worker.wasm" 
    type="application/wasi" context="serviceworker"></script>
  <script 
    id="sharedworker" src="./shared-worker.wasm" 
    type="application/wasi" context="sharedworker"></script>
</body>

Downsides

  • It's harder to write web applications using native code.
    • Currently thousands of large companies are struggling to scale JavaScript/TypeScript based web applications. Literally pouring millions of dollars on the development of custom bundlers, linters, wrangling with workspaces and costly SSR circuits all to improve an 8 second load time by 500ms (this is where I work).
    • It's unfair to nerf the capabilities of the web as a safety belt for simple use cases produced by developers earlier in their career. How many forests have we burned down just running online banking applications that could use 5mb of RAM rather than 400mb?  
    • This doesn't mean a replacement for JavaScript, but in high performance applications that companies are struggling to optimize/scale with JavaScript, it would be game changing.

Rolling something like this out would literally revolutionize web development

 

Comment
1 Comment
Status changed to: New idea
Jon
Community Manager
Community Manager
‎02-03-2026 01:04 AM
‎02-03-2026 01:04 AM

Thanks for submitting an idea to the Mozilla Connect community! Your idea is now open to votes (aka kudos) and comments.

Copyright © 2026 Khoros, LLC