There's the Wayland compositor on the web, Greenfield[1]. The project architecture changed some & I forget exactly how it works. This is a key step in getting a kind of normal Linux desktop running on the web, as I see it. This is how modern freedesktop apps are expected to draw & be managed, defines how display surfaces are handled & composited.
But even with Greenfield, getting things rendering & drawing is going to be a big challenge. Total Annihilation probably runs an old directx for graphics. We'd need some way to support that.
There's projects like DXVK[2] and VKD3D[3] to run directx 9/10/11 and 12 atop Vulkan. These are probably too new for a classic like Total Annihation, but would support many games. Yet, the web doesn't have Vulkan- it has a similar but different/less capable WebGPU. Perhaps someone could craft/hack-out another adapter layer, a Vulkan-atop-WebGPU translator, that could be stacked up. Or we could build WebGPU backends for these adapters. This is a pretty non-trivial effort. It's notable that projects like wgpu exist to provide a cross platform support for WebGPU, so if one were to build a DirectX-on-WebGPU translator, wgpu would let that game run on basically any platform: it'd be way cool. But again, that sounds like hella work.
There's a ton of other technical problems. Huge challenge #2 is that most games are precompiled for x86. Ideally we'd need to recompile them for webassembly, but it's unlikely many games would ever get ported. They could run at radically reduced speed via some machine-translation and games like TA might even work ok that way, given how much faster even a cellphone is than the pentium166 i rocked TA out on.
Challenge #3 is platform. These games rely on an native platform support for files, sockets, and dozens of other event loop & other concepts. Given time & effort, doubtless many of these could be platform libraries could be re-implemented. Projects like UMass's Browsix[4] purported to create similar platform libraries web-natively, creating a Linux-y/POSIX-y environment in the browser. This could perhaps be mated to something like Emscripten to expand the platform offerings significantly. Emscripten itself has adjacent projects for some platform support. Oh, wow, TIL it has OpenGL->WebGL conversion layers: some games could concievably be recompiled with emscripten without too too much fuss & work. But this would not be a Linux desktop, it would be just the game, in a canvas. There are projects such as QuakeJS[5] that appear to do just this!
The web itself is evolving many similar-ish capabilities for this #3. WebTransport is a better WebSocket that comes closer to being a viable network layer, and one day may perhaps, if we're all really really lucky, become a transport for WebRTC as well (fingers crossed). There are various File System API and File System Access API proposals going around for talking to files, which are only kind of semi needed, as a virtual filesystem is probably fine.
[1] https://github.com/udevbe/greenfield https://news.ycombinator.com/item?id=29239781 (71 points, 3 months ago, 26 comments)
[2] https://github.com/doitsujin/dxvk https://news.ycombinator.com/item?id=16199332 (216 points, 4 years ago, 51 comments)
[3] https://wiki.winehq.org/Vkd3d
[4] https://browsix.org/ https://github.com/plasma-umass/browsix many popular discussions, 5~6 years ago: https://hn.algolia.com/?q=browsix
[5] http://www.quakejs.com/ https://news.ycombinator.com/item?id=22797060 (357 points, 2yr ago, 158 comments)