4 ms·

> how does this work on Github Pages Spectre called for some drastic measures, and it'll be up to Github/Netlify to decide how they react. Developers who want

> how does this work on Github Pages Spectre called for some drastic measures, and it'll be up to Github/Netlify to decide how they react. Developers who want simple hosting solutions for their little projects will host elsewhere (e.g. replit.com, glitch.com) if they need to. This isn't exactly a massive obstacle if you've set out to build a complex game in the browser. It's just a couple of headers... >How long until this shows up in Firefox WebRTC data channels work fine in the mean time. Have you seen games like krunker.io and dotbigbang.com et al? It's perfectly possible to create real-time games in the browser using WebRTC.

meheleventyone 5y ago
And we’re using WebSockets right now for the networking in dot big bang! Although we’ve talked a lot about moving to WebRTC we’ve not gone as far as doing it yet. More generally things get a lot simpler if you’re “web first”. It’s a lot easier to just be pragmatic about it and build when you’re not straight jacketed by existing designs reliant on common low level OS APIs.
flohofwoe 5y ago
> This isn't exactly a massive obstacle if you've set out to build a complex game in the browser. It is an obstacle (at least a massive annoyance) for library authors (like this: https://github.com/floooh/sokol https://github.com/floooh/sokol). Those libraries can be used for extremely simple and small WASM snippets embedded in blog posts (like here: https://floooh.github.io/2019/01/05/wasm-embedding.html https://floooh.github.io/2019/01/05/wasm-embedding.html), or in "proper" games hosted through "proper" hosting services which allow to set the response headers. Right now the choice is to either support WASM threading, but tell library users that the library will most likely not work on the hosting solution of their choice, or not support WASM threading and work everywhere. At least to me it's clear that "works everywhere" is better than "it's complicated", so I'll ignore WASM threading until the problem is solved somehow (either most hosting services turn on those response headers, or there's another way to enable threading without requiring control over the web server configuration).
- rewq4321 5y ago
  > It is an obstacle (at least a massive annoyance) for library authors Yeah that's a completely fair point. Ruffle dev makes a similar argument up-thread: https://news.ycombinator.com/item?id=27199260 https://news.ycombinator.com/item?id=27199260
lights0123 5y ago
> Netlify Netlify already allows full control over headers even on their subdomain, including COOP/COEP.
- rewq4321 5y ago
  Oh, good to know!

meheleventyone 5y ago

And we’re using WebSockets right now for the networking in dot big bang! Although we’ve talked a lot about moving to WebRTC we’ve not gone as far as doing it yet. More generally things get a lot simpler if you’re “web first”. It’s a lot easier to just be pragmatic about it and build when you’re not straight jacketed by existing designs reliant on common low level OS APIs.

flohofwoe 5y ago

> This isn't exactly a massive obstacle if you've set out to build a complex game in the browser. It is an obstacle (at least a massive annoyance) for library authors (like this: https://github.com/floooh/sokol https://github.com/floooh/sokol). Those libraries can be used for extremely simple and small WASM snippets embedded in blog posts (like here: https://floooh.github.io/2019/01/05/wasm-embedding.html https://floooh.github.io/2019/01/05/wasm-embedding.html), or in "proper" games hosted through "proper" hosting services which allow to set the response headers. Right now the choice is to either support WASM threading, but tell library users that the library will most likely not work on the hosting solution of their choice, or not support WASM threading and work everywhere. At least to me it's clear that "works everywhere" is better than "it's complicated", so I'll ignore WASM threading until the problem is solved somehow (either most hosting services turn on those response headers, or there's another way to enable threading without requiring control over the web server configuration).

rewq4321 5y ago
> It is an obstacle (at least a massive annoyance) for library authors Yeah that's a completely fair point. Ruffle dev makes a similar argument up-thread: https://news.ycombinator.com/item?id=27199260 https://news.ycombinator.com/item?id=27199260

lights0123 5y ago

> Netlify Netlify already allows full control over headers even on their subdomain, including COOP/COEP.

rewq4321 5y ago
Oh, good to know!