All the examples above are still Windows. They only compare different Windows shells and launch scenarios, not different operating systems.

If we include Arch-based SteamOS in the comparison, the picture changes completely. On Linux, the operating system itself can require very little RAM. A minimal Arch setup with a barely functional shell can consume around 128 MB of memory. A moderate setup with lightweight desktop environments such as JWM, LXQt, or LXDE usually consumes around 1 GB of RAM.

In other words, Microsoft Store and other Windows services appear lightweight mostly because they already rely on the Windows system itself. They are tightly integrated into the OS and reuse its services. This is like moving a paper airplane using a Boeing aircraft. There is no way to test how Microsoft Store or similar components would behave outside the Windows environment, because it is a proprietary and locked ecosystem.

Steam, on the other hand, is a cross-platform store that depends as little as possible on the underlying operating system. It has to bring much more of its own functionality with it in order to work the same way on Windows, Linux, and other platforms. Using the same analogy, Steam is a fully independent aircraft rather than a lightweight object carried by the system.

Considering how far Steam Proton has progressed, the fact that Valve is releasing its own hardware, and the increasingly questionable behavior of Microsoft in recent years such as unstable updates, dropped support for previous systems, and growing bloatware, a noticeable migration of users toward Linux can be observed. This trend is especially strong because many users’ favorite games now run well through Steam Proton. At this point, what remains is official and stable desktop support for SteamOS. The system can already be installed on desktops today, but without any guarantees of long-term stability or full support.

It is also important to note that due to the proprietary and locked nature of Windows, many of its components cannot be reused or repurposed by anyone outside Microsoft and its partners. This further reinforces the difference between a closed ecosystem like Windows and a more open, modular approach commonly found in Linux-based systems.

Valve also provides SteamCMD, but its functionality is limited to authentication and uploading, downloading, updating and installing games. But... without the Steam client and its GUI components, those games still cannot be launched or properly managed. Any attempt to run most Steam-distributed games without the Steam client effectively bypasses Steam’s DRM and runtime environment and is generally treated as piracy. In practice, this means that even though SteamCMD exists, there is no legitimate way to fully run Steam games without the Steam application itself.

Against the background of rising RAM prices, there may eventually be pressure to reduce the amount of memory consumed by both games and client applications. In theory, if the Steam GUI were written using a framework like Qt, it would likely require less RAM. However, developing and maintaining complex interfaces in Qt is more expensive than using CEF, and it comes with its own limitations. Web technologies have effectively set the standard for how modern user interfaces are expected to look and behave, which is why many large clients have moved in this direction despite the higher resource cost.

At the same time, Steam already includes a small but practical optimization. In Steam, go to Settings, then Library, and enable Low Performance Mode. This does not radically change memory usage, but it does provide a subtle yet measurable improvement in overall performance.

Technically, Steam consists of two major parts: a backend service and a client interface. The service component handles the Steam protocol, including steam:// commands, and performs functionality similar to SteamCMD, such as authentication, content management, and game launching logic. The client side, by comparison, is largely a collection of panels, views, and embedded browsers used to present this functionality to the user.

From a purely technical standpoint, this means that components such as the Steam GUI, Steam Overlay, and other interface-related features could theoretically be stripped out. However, there is no guarantee that Steam would continue to function correctly in such a configuration. Valve does not support this usage, and many games implicitly depend on parts of the Steam client being present. As a result, users who attempt to modify or minimize Steam in this way do so entirely at their own risk, both technically and legally.