Rendering to WebGL

[merryman]

This is more of a braindump but I am leaving that here since I was stumbling once again over what the folks at https://github.com/makepad/makepad are coming up with.

Makepad has essentally done what seems crazy at first but seems to resolve a lot of performance issues in the browser down the line: Entirely bypass the Browser and handle everything in wasm by directly rendering to WebGL. The results are quite impressive, take a look: https://makepad.dev/.
Just as lively.next this is an IDE writting in itself, any parts can be changed at runtime and take immediate effect. The performance is also staggering. Particle and Agent based simulations with hundreds of thousands of objects that are quite unheard of in JS/HTML land are not a problem here at all. Tough this is nothing new and has been demonstrated years ago by yoshiki's https://github.com/yoshikiohshima/Shadama it is still sobering to see the implications.
HTML/CSS still is and will always be optimized for documents and the rather surprising freedom you get from leaving those constrained formats behind you made me think.

The plan of Makepad is to eventually build a IDE makepad-studio that can target any platform from web to desktop.
A recording of a very basic figma prototype (so essentially just a couple animated drawings) can be found here: https://www.youtube.com/watch?v=YzFNoNUP3x8
Similar to lively.next they aspire to solve the issue of separation between designers and programmers working in different realms by letting designers create components that then can be utilized by the programmers. I am especially excited to see the programming model they want to solve this with. From what I hear this is going to be achieved by a custom DSL that drives any of the apps that are built within makepad-studio. Presumabley this will allow them to have a clearcut reconciliation between changes in code and changes in the visual (designer world), but I wonder how they will reconcile programmer's abstractions with the lego-like world the designers live in. Furthermore they are embarking on a brave new world where all they rely on is mainly stuff that can be easily hooked up with Rust. The convenience of JS land ist still that I can go to any website and if something catches my eye, easily figure out the library behind (for rendering maps, charts, spreadsheets, computing astronomical events, you name it) and import it into lively with a single line of code. This is not the case with wasm applications who ship as binaries. Even moreso, the composability of different visual rendering libraries is not as convenient as in the DOM. That is also what has kept me from swapping out the morphic rendering to something like Canvas or WebGL or even moving to the approach of Makepad, which divorces itself completely from this ecosystem and creates its own runtime. (Think of a smalltalk env entirely compiled to webassembly and rendering to WebGL).
So they are of course hedging on the prospect that the gigantic ecosystem of libraries existing in JS will eventually succumb to the convenience of a platform that allows the user to deploy conveniently to any target. Interesting to see how that will pan out.
Also I have yet to see how they hook up a decent debugging interface into the system. I do not know do what extent debugging rust processes inside the browser from within the browser is matured yet but that may be a significant way to go still.