It is so slow. It consumes excessive memory causing performance issues and lag in my game. That is likely what comes to mind when I talk about device customization software. At least, that is what I have observed. 

Traditionally, larger companies build software, with the primary focus on making it easy to hire new engineers to build and support the software. This has led to the widespread adoption of web technologies like JavaScript, HTML, and CSS.

Atwood’s Law: Any application that can be written in JavaScript, will eventually be written in JavaScript

This trend has made its way into the desktop world through frameworks like ElectronJS, which allows web developers to create desktop applications using familiar web technologies. While it has its advantages, it just wasn't for us. We have chosen to go native. This article is going to talk about why we made this choice.

Our goal

The goal was simple. Build a lightweight, responsive app that allows users to customize their Phase inputs, tweak its settings. Let's break that down into our rules

1. Low latency: The app needs to respond to joystick inputs in real time. Even a slight delay would ruin the experience.

2. Minimal resource usage: Since the app runs in the background, it shouldn’t hog CPU or memory, especially when our users are gamers who are running other resource heavy games.

3. Deep System Integration: The app needs to interact with low-level hardware APIs and handle system events like device connections seamlessly.

4. Responsive: The UI should feel natural and smooth. It should feel like just another native windows application and should work for multiple version of the OS

Why Electron wasn't for us

Performance

Electron apps are essentially Chromium browsers running a web app. This means that every Electron app ships with a full browser engine, which comes with a hefty performance cost.

• Memory Usage: Even a simple Electron app can eat up hundreds of megabytes of RAM.

• CPU Usage: The Chromium renderer and Node.js runtime add unnecessary overhead, which can slow down the system when you’re running games.

  
  

Build Size

Since every electron app bundles a chromium browser, the installer size can easily cross 100MB. For a background app this feels excessive. It also makes distribution and updates more complicated

Non native look

Electron apps often feel out of place on Windows. Although you can style them to look somewhat native they never quite match the polish of a true Windows app. For a joystick customization tool, where users might spend time tweaking settings, we wanted something that felt like it belonged on Windows.

Towards WinUI

WinUI is a native user experience (UX) framework for both Windows desktop and UWP applications. It is built on the Windows App SDK and provides direct access to the lifecycle management, resource management, and native Windows functionalities. 

Performance

Working directly with the Window App SDK means it’s extremely efficient 

• Memory Usage: Our app uses a fraction of the memory compared to what it would on Electron. Over extended period of time, we have observed our app consumes around 50 MB of memory

• CPU: Since it’s native, there is no browser engine that add to the CPU consumption. Compared to an electron app for controlling the mouse, our app consumes less than half of the CPU percentage.

  
  

Native Look and Feel

WinUI 3 is designed to align with Microsoft’s Fluent Design System, so our app looks and feels like a proper Windows app.

Build Size:

Our build size only comes under 50 MB. 

Conclusion

For our joystick customization software, WinUI 3 was the clear winner. It delivered the performance, system integration, native feel, and compact build size that Electron simply couldn’t match. Although Electron does have its place for building cross-platform apps and easy to maintain web based infrastructure, it does not meet most of our requirements.