Jonathan Blow

Well paging @gordonbrander here but this is inevitable. I don't mean the deployment of <canvas> for other than images, but the evolution of the browser beyond an engine for text-serving and rendering. The /existinence/ of <canvas> already less 'democratic' than 'ol <img>https://twitter.com/MidasNouwens/status/1392756740962332674 …

https://twitter.com/gordonbrander/status/1392901309712408576 …

Worth considering that the contending alternative architecture is likely to be Mighty. Basically, thick edge, thin cloud ~vs~ thin edge, thick cloud.

I am still thinking about it all. Had assumed @Suhail was going to get crowned with laurels on Mighty launch, and the pushback has made me think again a little bit about edge vs near-edge vs vs distributed vs central cloud. The application space I am focussed on is built design.

In built design, no one gives a fk about DOM and it's all a universe of workarounds. @threejs by @mrdoob is a v kindly workaround, but still a workaround (obviates a plugin), but it's not WASM, and it leaves a payload problem (where and how to serve the file that 3js renders).

@HyparAEC is working magic in this space, but IMO will rapidly come up against an execution speed problem bc cloud-serve and pure browser-render will just hang too long to be a smooth exp. IMO Mighty (ie shell on cloud exec) won't be the path here, though yes on other uses.

Our speed problems are self inflicted. We render gltfs of arbitrarily large models on the server, then download them in the client. There's no reason a fully browser based geometry app can't be lightening fast. Computers are faster than most people understand.