🕸️ Web support

[iceiix]

Support running on the web platform target, in addition to the "native" (Windows/Linux/Mac) platform currently supported

• [x] wasm (#92)
• [ ] graphics
  • [x] glow (#262, #171)
  • [x] web-sys (#444)
  • [x] shaders compile
    • [x] remove glTexImage2DMultisample (#447)
    • [x] disable geo shader (#448)
  • [ ] multisampled renderbuffer (#442)
  • [x] display something on the screen (#451)
• [x] std::time (#449)
• [x] rand (#450)
• [ ] file I/O
  • [x] std::fs::File placeholder (#444)
  • [x] bundle resources statically (#483)
  • [ ] resources downloading
  • [ ] persistence
• [ ] chunk_builder
  • [x] disabled (#451)
  • [x] single-threaded (#458)
  • [ ] multithreaded / web workers
• [ ] events
  • [x] events loop (#459)
  • [ ] Pointer Lock API
• [ ] textures
• [ ] networking
  • [ ] reqwest blocking -> async (#660)
  • [ ] web sockets
  • [ ] tcp
• [x] CI (#486)

[iceiix]

Found this new project (via https://wiki.vg/Client_List) with similar goals: https://github.com/PrismarineJS/prismarine-web-client It is further along in web support (actually works) than us, though needs optimization. Being written in JS, likely easier to develop, but harder to optimize than Rust.

Maybe worth contributing there instead or in addition to this project, could be useful to have a working alternative web client for reference.

[PureTryOut]

Are you planning on dropping web support then? Seeing your comment in https://github.com/iceiix/stevenarella/issues/581#issuecomment-893507084 makes me think so at least. Personally I love the idea of a webclient, but I don't think it's worth it if it blocks stuff like a renderer upgrade. Desktop platforms should probably be the number 1 priority.

[iceiix]

@PureTryOut I'm of two minds in removing web, it may help increase maintainability (lots of the dependency updates are web-related), but I do feel it is getting there, very close - the major missing piece is networking (well, also multithreading, and resources). The "rendering upgrade" I settled on was to use glow (GL on Whatever, #262), this abstracts away OpenGL/WebGL, but another possible upgrade, a different abstraction (was considering in #34, but it didn't seem there yet) is wgpu-rs. If/when Leafish supports wgpu or Vulkan (https://github.com/terrarier2111/Leafish/issues/20), I think that does appear to be a viable option - for also supporting the web (WebGPU).

My current thinking is its a good idea to keep (incomplete) web support around, so as I make changes I can ensure it at least still continues to compile for the web, but I may be wrong about this. If I had to choose, I'd be tempted to go with a new rendering backend (as long as it works on my macOS system too).

[iAmInActions]

Idea for networking: use a generic websocket proxy like for example wss://relay.widgetry.org/. From my testing in v86 is seems to be reliable and supports port 25565. Chunk loading might be a bit slow though as the proxy limits the bandwidth for each connected device due to it being a free proxy.

[mpfaff]

To be completely honest, that sounds like a really bad idea. If you were to go that route (using a websocket proxy), you'd have to make it easily configurable or at the very least, include a big notice when you use it. Also, wouldn't the free proxy have a bandwidth, speed, or connection limit that would be a problem if stevenarella ever gets big? Just seems like you'd be digging yourself into a hole that would be tough to get out of.

[iceiix]

I think supporting the use of a public proxy could be an interesting experiment, but agree it has pitfalls making it probably not the best solution for normal everyday usage - bandwidth/connection limits, using a shared IP address, etc.

I was thinking instead the WebSocket proxy could be setup by the server owner, who wishes to make their server available through the "web". A plugin serving both WS and HTTP, for the web-based client which connects back to the WS, inspired by this plugin: https://www.spigotmc.org/resources/websandboxmc.39415/ - but more full-featured.