in this case, no. it's a client game and performance isn't at all critical, so the state and loop could be trivially handled by a regular js function. if at some point a server architecture was desired, it would be trivial to host that function on node.

my take: as a backend developer he was fixated with the idea of having a server no matter what (if your only tool is a hammer, everything looks like a nail), and as go was his main language he just went with that. then he figured out it didn't really have a point, but instead of just translating that simple logic to js he overengineered the whole thing and overcomplicated his design and build process by transpiling to wasm.

there are some bugs, though. i just won a couple of matches at escoba (very nice little game, i hadn't played this for ... decades!) and the game state wasn't properly reset for the next. that's probably the llm ...

Nah, whatever bug you're referring to is my fault, haha, don't blame the LLM. But in between game state bugs are very unlikely, haha: https://github.com/marianogappa/escoba-de-15/blob/main/src/A...

I can't imagine state surviving a location reload with nothing on local storage and no server.