Add Native Deno Integration as a Dedicated Backend Layer in Tauri

[wmadfaa]

Summary

Currently, Tauri follows a two-layer architecture:

1. Frontend – the web-based UI (HTML/CSS/JS/TS/React/etc.)
2. Backend – the Rust core, handling both native OS APIs and backend logic (e.g., DB access, file operations)

This proposal suggests expanding Tauri into a three-layer architecture by introducing a new, officially supported Deno-based backend layer, while the Rust core focuses solely on native OS operations.

---

Proposed Architecture

Introduce an official Deno runtime layer within Tauri apps:

1. Frontend

   • The existing webview-based UI layer

2. Backend (New Layer)

   • Powered by Deno runtime (v2)
   • Handles business logic, APIs, DBs, file access, etc.
   • Written in TS using Deno's secure runtime and standard APIs

3. Native Layer

   • Rust layer that handles low-level OS-native APIs (system tray, file dialogs, window control, etc.)

---

Communication Model

All three layers—Frontend, Backend (Deno), and Native (Rust)—should be interconnected using the same messaging/invocation system currently used between frontend and backend (e.g., invoke, emit, listen).

---

Benefits

• JS/TS Developer-Friendly: Enable full-stack JS/TS workflows without requiring Rust knowledge.
• Clean Separation of Concerns: Business logic and OS-native logic are clearly divided.
• Security: Deno's secure-by-default permission model adds an additional layer of safety.
• Modularity: Encourages well-structured codebases with independent responsibilities.
• Broader Adoption: Lowers the barrier for full-stack web developers adopting Tauri.

---

Why Not Just Use the Existing Deno Plugin?

The community Deno plugin is promising but:

• Is not officially maintained by the Tauri team
• Grants full permissions (no sandboxing)
• Has known issues (e.g., Windows production binary issues)
• Does not behave as a true architectural layer—it’s an embedded script runner

---

Would love to hear feedback from the Tauri core team and the broader community.

[FabianLars]

Thanks for the extensive write-up. #4670 is our overarching tracking issue which also includes Deno.

Our current core team cannot handle anything official so we have to rely on community contributions like the deno plugin or the python experiments you see in 4670. We're open to collaborate on changes required to make tauri more accessible and we've already seen such changes mainly thanks to @WSH032.

I also believe that features like these really have to start outside of Tauri so that they can better do experiments to get it right, and to make sure that in the end tauri is changed in such a way that new backend languages can be added relatively easily ideally without having to be inside tauri or requiring major changes. Similar to how the winit crate is restructuring their code base at the moment if you've seen it.

Also, i think there's a common misconception about how tauri's team works. The working group is very open so in theory we could add the maintainer of the deno plugin to the group (basically no requirements) and nothing would change. The only thing here would be something like an "official" label, it would not change/help its quality and it would just further manifest that misconception.

[wmadfaa]

Thank you for the quick response,
I'll take some time this weekend to deep dive into the current plugin's capabilities provided by Tauri.