| ▲ | playorizaya 4 hours ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | firesteelrain 4 hours ago | parent [-] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||