@Damned_Yankee a web-based Zwift is technically possible, but with drawbacks.
Current iteration of Zwift relies heavily on networking and a bit on web (the auth dialog uses embedded browser, while the main app is a “native” app).
3D-accelerated applications in a browser are totally a thing thanks to WebAssembly, WebGL and upcoming WebGPU. Modern video game engines like Unity and Unreal Engine have browser target support. From what I read, Zwift runs on a bespoke engine, which means developers can’t benefit from browser support out of the box, they’ll have to spend extra effort to add it.
The other major issue is much more modest API surface in browsers. A “native” application has access to pretty much any API the host OS provides, which is not the case with browsers due to various reasons,
security and standardization process among them. For Zwift, this means no easy access to Bluetooth or ANT+ devices. Google Chrome and derivatives support Web Bluetooth API and WebUSB, but Mozilla Firefox and Apple Safari do not. For browsers without the API support, a bridge similar to Zwift companion is the only option. Zwift now suddenly requires a mobile device or a tiny-bit native app (for personal computers) to function at all.
There are other, more nuanced aspects to this, but it all boils down to balance between how much time the development will take and the monetary benefit the change will bring. I very much doubt a browser Zwift will be of significant value to the company or users. Given how unresponsive Zwift are to even the most basic and well reasoned user change requests (UI, plans UX to name a few), I would not expect anything of the sort happen at all, unless major variable changes happen.
