1. It's not really running containers in the browser, right? It seems every service would need a custom connector - and more importantly...
2. ...would need a renderer, right? Otherwise what does it mean to be "ported to the browser"?
To use an analogy - if somebody ported DOOM to the browser, that means I can now play it in the browser. But I can't really run those databases that it shows in the browser tab, can I?
I couldn't say spin up ruby2d and suddenly have client-side Ruby support. It would require all sorts of custom work to get that actually running in a browser tab.
Where presumably with typical backend container services they really can port around and run anywhere.
So I don't see the point, and someone correct me if I'm wrong but it doesn't even seem to be what it asserts.
Your points are addressed in the post just not in the title.
It’s not running real container images. Maybe a better idea is simulated Kubernetes.
What’s ported is the control plane: scheduler, kube-proxy, deployment controller, etc, transliterated from the actual Go source and tested against k3s for behavioral parity using the same client API. The “rendering” is the demo app visualizing pod-to-pod requests as moving dots.