raylib-5k VS temporal-polyfill

A game made with it for raylib game jam along with the raylib bindings and other engine stuff: https://github.com/nikki93/raylib-5k

I do also really like Go for various reasons, and have been working on a Go -> C++ transpiler and associated ECS libs to make a personal game project with. I used it to make a game for Raylib game jam earlier this year too: https://github.com/nikki93/raylib-5k You can see what the development workflow looks like in this video (the ECS stuff also has an editor): https://www.youtube.com/watch?v=8He97Sl9iy0

I'm trying to decide how much time I should devote to making this easier to set up / use by other people in the medium term, since it's just a side project for me. Might make a codespaces template so it's quick to get started.

For the client I use a simple go -> c++ compiler I wrote and compile to wasm from that actually. It had zero overhead interfacing to / calls to C/C++ (including generics<->templates) since it's just generating that. Example web game made with that: https://github.com/nikki93/raylib-5k

I think I've seen wasmtime before. If I needed to interface to any C/C++ things on the server I would probably just write in C/C++ (or Gx) yeah.

Sweet! I've been using it for the same. Example game project (did it for a game jam): https://github.com/nikki93/raylib-5k -- in this case the Go gets transpiled to C++ and runs as WebAssembly too. Readme includes a link to play the game in the browser. game.gx.go and behaviors.gx.go kind of show the ECS style.

GitHub repo: https://github.com/nikki93/raylib-5k

There's another, much smaller polyfill: https://github.com/fullcalendar/temporal

This assumes two things though, and this is another point I just realized about WASM that I like, which is for (most) modern browsers asm.js / WASM doesn't have to be polyfilled, therefore with Temporal we have to consider the following:

1. Browser support - its not there yet. you'd have to polyfill. A production level polyfill is 16 KB, and is still very nasacent, and, on top of that, requires support also for BigInt[0]. The polyfill that tc39 put out is decidedly marked as non-production ready[1].

2. Polyfilling - as mentioned above, we have to deal with polyfilling the API, and that isn't a clear and easy story yet. WASM support goes back farther than this.

3. Size - its entirely possible to get WASM builds under 16 KB, and the support is better, espcially for operations on strings and numbers (dates fit this category well). The only complication I haven't quite solved yet is:

A) Can I validate that a WASM build will be under 16 KB. This is crucial. I'd even accept it at 20 KB because of wider browser support[2]

B) Can I fall back to asm.js if needed (there is a slim range of browsers that support ASM.js but not WASM, mostly pre-chromium Edge[3]

C) Is it performant compared to something like Luxon or date-fns? WASM excels at string / numerical operations so my sneaking suspicion is yes, at least in terms of the WASM operations. The complexity will be serializing the operations to a JS Date instance, Luxon & the Intl API might be most useful here

[0]: https://github.com/fullcalendar/temporal/blob/main/packages/...

[1]: https://github.com/tc39/proposal-temporal#polyfills

[2]: https://caniuse.com/wasm

[3]: https://caniuse.com/asmjs