Proposal: Consider GPUI + Lua as a Native, Lightweight Alternative to Tauri + JavaScript/TypeScript

[m64s]

Overview

I would like to propose considering an alternative architecture for Asyar: using GPUI (from Zed IDE) for the UI layer and Lua for extensions, instead of Tauri + Svelte/JavaScript/TypeScript.

I think this could be particularly interesting for Asyar because of the nature of the application itself.

Asyar is not typically an application that users launch, perform one task in, and then close. It is more like a persistent system utility / launcher that may remain running in the background for hours or even days. Because of that, startup time, idle CPU usage, memory consumption, and general runtime overhead are especially important.

Why GPUI?

The current architecture provides many advantages through web technologies, but it also introduces a WebView-based UI layer and the associated runtime overhead.

With GPUI, the architecture could potentially become:

                 Asyar
                   │
                GPUI UI
                   │
                Rust Core
                   │
        ┌──────────┼──────────┐
        │          │          │
       OS        Search      MCP
       APIs      Indexing    / AI
        │
      macOS

This would make the application essentially a native Rust application from the UI down to the system integration layer.

It could eliminate the need for:

• Tauri's WebView-based frontend
• Svelte/React/etc. for the main UI
• DOM-based rendering
• Frontend ↔ backend IPC for normal UI operations
• A JavaScript runtime for the core application UI

Instead, the UI and the native core could communicate directly within Rust.

I think this could be especially valuable for a launcher that is expected to feel instantaneous whenever the user invokes it.

Why Lua for Extensions?

I think Lua could complement GPUI particularly well as an embedded scripting language for extensions.

Instead of requiring a JavaScript runtime for extensions, Asyar could embed a lightweight Lua runtime:

                 Asyar
                   │
                Rust Core
                   │
              Lua Runtime
                   │
        ┌──────────┼──────────┐
        │          │          │
     Extension  Extension  Extension
         A          B          C

Extensions could interact with Asyar through a controlled API such as:

asyar.clipboard.read()
asyar.apps.search(...)
asyar.files.search(...)
asyar.notifications.show(...)
asyar.ui.list(...)

The Rust layer would remain responsible for the actual OS operations and permission enforcement.

This could also make it possible to keep extensions extremely small compared with a typical JavaScript-based extension stack.

Resource Usage Matters More for Asyar

One of the main reasons I think this is worth discussing is that Asyar has a different runtime profile from a normal desktop application.

A typical application might be:

Open → Use → Close

while Asyar is more like:

Boot
  ↓
Asyar starts
  ↓
Runs in background
  ↓
User invokes it occasionally
  ↓
Returns to background
  ↓
Repeats
  ↓
Hours / days later

That means a few milliseconds of startup time are important, but so are the resources consumed during the other 99%+ of the time when the launcher is simply waiting in the background.

For this type of application, I think the following metrics deserve significant attention:

• Idle memory usage
• Idle CPU usage
• Background wakeups
• Startup time
• Hotkey-to-visible latency
• Extension startup latency
• Memory overhead per extension
• Long-term memory stability
• Number of processes
• Runtime dependencies

A native GPUI + Rust architecture could potentially reduce several layers of overhead simultaneously.

Potential Architecture

Something like:

                         ASYAR
                           │
                     ┌─────▼─────┐
                     │   GPUI    │
                     │ Native UI │
                     └─────┬─────┘
                           │
                     ┌─────▼─────┐
                     │   Rust    │
                     │   Core    │
                     └─────┬─────┘
                           │
          ┌────────────────┼────────────────┐
          │                │                │
        OS APIs          Search           AI/MCP
          │                │                │
          └────────────────┼────────────────┘
                           │
                     ┌─────▼─────┐
                     │    Lua    │
                     │ Extensions│
                     └───────────┘

This could potentially make the entire application a single native ecosystem:

Rust → GPUI → Lua

rather than:

Rust → Tauri → WebView → Svelte/JS → Extension WebView → JS runtime

Trade-offs

I don't think this would be strictly better in every respect.

The biggest trade-off would probably be the extension ecosystem.

The current JavaScript/TypeScript approach gives extension developers access to the enormous npm ecosystem and makes development familiar to a very large number of developers.

Lua would have a much smaller ecosystem.

There would also be a learning curve for developers who are not familiar with Lua, and implementing a good extension API and sandbox/capability system would require significant engineering work.

Another possibility could therefore be supporting both:

                    Asyar
                      │
             ┌────────┴────────┐
             │                 │
            Lua              JS/TS
        Lightweight        Full ecosystem
        extensions          extensions

Lua could be the default/recommended option for lightweight extensions, while JavaScript/TypeScript could remain available for extensions that genuinely benefit from the npm ecosystem.

What I am proposing

I'm not suggesting that the current architecture is bad, or that this should necessarily replace the existing implementation immediately.

Rather, I think GPUI + Lua is worth investigating as a possible long-term architecture, especially given Asyar's role as a persistent system utility.

A useful first step could be a small experimental branch/prototype implementing:

1. A minimal GPUI version of the launcher window.

2. Global hotkey → GPUI window invocation.

3. A small embedded Lua runtime.

4. A minimal Lua extension API.

5. One or two example extensions.

6. The same benchmark methodology used for the current implementation.

7. Direct comparison of:

   • RAM
   • CPU
   • startup time
   • hotkey latency
   • extension startup time
   • background wakeups

If the prototype does not provide a meaningful improvement, the idea can be discarded based on actual measurements.

If it does, it could provide a foundation for a significantly lighter and more native version of Asyar.

I would be very interested to hear the maintainers' thoughts on whether this direction would be technically feasible and whether GPUI/Lua has already been considered.

[Xoshbin]

Hi @m64s,

Thank you for putting together such a well-researched, thoughtful, and detailed proposal. You raised several valid points regarding background memory footprint and idle efficiency for persistent system utilities.

Here are my thoughts on where Asyar stands today, the trade-offs involved, and why a full architectural shift to GPUI is not on our immediate roadmap:

---

1. Current Performance & Diminishing Returns

Excluding Alfred (which is purely native Objective-C/Swift and macOS-only), there is virtually no cross-platform launcher on the market faster than Asyar today.

Asyar was built from day one around a "Rust-First" architectural invariant:

• Indexing, fuzzy searching, scoring, caching (SQLite), window management, hotkey handling, and MCP integrations all run natively in Rust.
• The web layer (Svelte 5 Runes) serves purely as a reactive presentation layer with pre-warmed windows.

Because the compute and IO heavy lifting are already 100% native Rust, hotkey-to-visible latency and search results feel practically instantaneous. Migrating the UI layer to GPUI would at best shave a few milliseconds of presentation overhead, which is not perceptible to human interaction, while costing a massive amount of development effort.

---

2. Project Stage: 3+ Years of Development Approaching Stable Release

Asyar has been in continuous, intensive development for more than 3 years in beta, and we are finally nearing our first stable release milestone.

Rewriting the entire UI, design system, settings, onboarding, windowing mechanics, and extension bridge in GPUI would take many months if not years of engineering effort. Undertaking a foundational architectural rewrite at this critical juncture would delay the stable release and destabilize years of battle-tested code.

---

3. Cross-Platform Windowing & GPUI Maturity

Launchers require delicate, platform-specific windowing behaviors across operating systems:

• Frameless, non-activating floating panels
• Native transparency & compositor blur/vibrancy (NSVisualEffectView on macOS, Acrylic/Mica on Windows, Wayland/X11 blur on Linux)
• Stealing and restoring focus seamlessly across multi-monitor setups

While GPUI is exceptionally fast and well-suited for macOS, its Linux (X11/Wayland) and Windows (DirectX/Vulkan) windowing implementations are still actively maturing upstream in Zed. Tauri 2 / Tao / Wry provides us with a rock-solid, cross-platform foundation today.

---

4. Extension Ecosystem: JavaScript/TypeScript vs. Lua

One of Asyar's core goals is ecosystem adoption. The JavaScript/TypeScript ecosystem (@asyar/sdk) allows the vast majority of desktop and web developers to build extensions immediately with familiar tooling and access to npm.

While Lua is lightweight and embeds cleanly, it creates a steep adoption barrier for community extension authors and makes rich, interactive extension UIs significantly harder to build and maintain compared to standard web components.

---

5. Future Possibilities (Polyglot / Script Extensions)

That said, I agree with your observation that simple commands (data-only or search providers) don't always need a full JS/DOM environment. In the future, exploring a lightweight embedded runtime (whether Lua via mlua or WebAssembly via wasmtime) as a complementary headless script provider alongside our TS SDK could be an interesting experiment without touching the core UI architecture.

---

I really appreciate you taking the time to share such a high-quality perspective and benchmark ideas with the community!

[m64s]

Thank you @Xoshbin for the detailed response. I have tried Asyar myself, and I agree that it is already extremely responsive. I also agree that a full migration from Tauri to GPUI would not be justified simply to reduce UI latency.

My original motivation was primarily resource usage, rather than responsiveness. Since Asyar is designed to remain running in the background for long periods, I think idle and long-term resource consumption are particularly important:

• Idle RAM usage
• Idle CPU usage
• Background wakeups
• Memory growth over long periods
• Resource overhead from loaded/unloaded extensions

Rather than assuming Tauri/WebView is the main source of overhead, I think the more useful question is where the current resource usage comes from and whether it is significant enough to optimize.

I also think your suggestion of a lightweight headless runtime for simple extensions is very interesting. Lua via mlua or WASM via wasmtime could potentially reduce the overhead of extensions that don't need a full JS/DOM environment, while keeping the existing TypeScript SDK for richer extensions.

That said, with modern AI coding agents, I don't think experimenting with such architectural changes necessarily has to take months or years. If the scope is carefully limited—for example, replacing the UI layer while preserving the existing Rust core and APIs—it may be possible to prototype and evaluate the idea relatively quickly.

A long-running resource benchmark (e.g. RAM/CPU after 1h, 6h, and 24h with different extension configurations) could first establish whether there is actually a meaningful optimization opportunity.

Thanks again for the detailed explanation!

[Xoshbin]

Hi @m64s,

Thanks for the thoughtful follow-up and sorry for the delayed reply! You make very fair points, especially regarding long-term resource tracking (RAM soak, idle wakeups, and background timers). Let me address the points you raised:

---

1. On Long-Running Benchmarks & Idle Resource Usage

You asked where the current resource usage comes from and whether long soak tests have been conducted. This is actually an area we’ve been actively profiling and optimizing:

• Recently, @AllDaGearNoIdea ran an extensive idle investigation including an 8-hour soak test and side-by-side comparisons with Raycast Beta (detailed in PR docs: idle-cost investigation report #608).
• The soak test confirmed no memory leaks on the Rust side over 8 hours, and deep-idle CPU was measured at 0.84% vs 0.76% (virtually tied with Raycast), with Asyar summoning 2.2x faster and holding ~35% less memory.
• Through recent PRs (perf(timers): skip idle 1Hz SQLite poll #606 and perf(watchers): cut debouncer ticks 8Hz to 2Hz #607), we also cut down background wakeups significantly by eliminating idle 1Hz SQLite timer polling and reducing filesystem debouncer ticks.

I'm still actively tuning areas like parked WebKit memory retention and extension disk I/O, so optimizing idle behavior is happening directly within the current architecture.

---

2. On AI-Assisted Prototyping vs. Project Priorities

You’re completely right that modern AI coding agents make building a self-contained prototype much faster than in the past.

However, Asyar is a solo project alongside contributions from great community members around the web. While whipping up a prototype is quick, integrating an emerging UI framework like GPUI into production across all three platforms (Wayland/X11, Windows, and macOS) still means dealing with delicate windowing behaviors, compositor blurs, focus stealing, and multi-monitor scaling.

After more than 3 years of development in beta, our top priority right now is finalizing and delivering our first stable v1.0 release on the architecture we’ve spent years refining. Shifting focus to a new UI layer at this stage would derail that milestone.

---

3. Looking Ahead

I'm certainly not closed to new ideas. Once the first stable release of Asyar is out the door, I'd be very open to exploring an experimental branch with GPUI and embedded Lua/WASM for learning, testing, and comparative benchmarking.

Thanks again for the great discussion and for taking the time to share your perspective!

[m64s]

Thank you @Xoshbin for the detailed response and for taking the time to address everything so thoroughly!

The main reason I opened this discussion was to exchange ideas and explore different architectural approaches Asyar is already an incredibly good and unbelievably fast application, and it is clear that a lot of thought and work has gone into the current architecture.

For me, there are two main goals behind the discussion:

1. Exploring different ideas and approaches — especially while the project is still relatively early and there is room to consider alternative directions.
2. Reducing resource consumption, particularly RAM and background CPU usage. For an application that is expected to stay running continuously in the background and behave almost like part of the operating system, I think the resource footprint is especially important.

Even if Asyar already outperforms Raycast in several performance metrics, I don't think that necessarily means it has reached the limit of what can be achieved. If there are architectural or implementation improvements that could make it even lighter, I think they are worth exploring.

For example, getting Asyar down to around 200 MB of RAM during normal idle usage would be fantastic in my opinion, especially for an application that may remain open for days or weeks.

Regarding the extension system, this is also why I wanted to bring up different approaches such as Lua or WASM before the ecosystem becomes too large. Since the extension store is still in its early stages, I think this is a particularly good time to consider different models before the store becomes filled with extensions that could make a future architectural change much harder.

Of course, I completely understand that getting v1.0 out is the priority, and I think that's the right decision. I'm looking forward to seeing where Asyar goes after the stable release.

Thanks again for the great discussion!

[Xoshbin]

Thank you for opening the discussion, I really enjoyed the chat with you I discovered some new stuff that I may one day follow up with it just for learning even if the main purpose would not be refactoring Asyar.

I know your main purpose where reducing the resource consumption, but as said the advantage of rebuilding Asyar with a new technology or stack my not worth it, because Asyar even though is still in beta and still tested and improved it's resource usage is very good so far. but as said that does not stop me and community contributers from improving it.

Thank you very much for the chit chat, and your issue reports, please continue contributing with bug reports and ideas, even if I may not be available, there would be someone else from the community to help.

[m64s]

Sure, I enjoyed this conversation as well. Thank you for this wonderful project and for your constant care and concern for the users.

Looking forward to what this project and its updates have to offer in the future.