Consider Pure JS Transpilation

[L1lith]

(Quote)
I haven't done any benchmarking, but I suspect that the rate-limiting factor is DOM API calls, which until interface types are implemented should be slower than JS.

That being said.. Benchmarks would definitely be useful as a way to help the libraries trend towards being more efficient over time. (as long as it isn't at the expense of usability.)
Originally posted by @chinedufn in #153 (comment)

Until native DOM access is implemented, I imagine it could be faster to manipulate the DOM by transpiling our Rust to pure JS to remove the interop bottleneck. This of course would need to be verified with performance metrics. Even after WebASM has been given native DOM access I believe this would be a really good feature for browsers that don't have WebASM enabled/implemented as a fallback mode.

Edit: I know this might be a large task, and I haven't looked at the feasibility of transpilation between Rust and JS, I do think it's worth looking at this though

[qm3ster]

Do you mean "readable JS" transpiration, like ReScript (ex Reason) or , or asm.js-style compilation (WASM precursor, the fastest JS subset, a target for compiling, say, C)?
Both are outside the scope of just this one framework, but I'm curious which one you meant.
As for performance of JS glue code, it seems acceptable.
The reason includes optimizations such as what is described here.
Once the situation with caching of already-compiled WASM modules improves in browsers, the worst part (startup time) will also be eliminated.

As for Percy specifically... Percy uses a virtual DOM. The vdom strategy has an unavoidable intrinsic cost.
JS Libraries like React, Preact, Inferno have spent years optimizing the performance of that, yet React is beaten by Yew (including current WASM overheads), which uses a vdom, but does that computationally intensive work in WASM.

Perhaps there is still a meaningful overhead to WASM-JS ffi, which is how solid.js still beats rust-dominator, despite not even having a SignalVec equivalent.

However, they both beat the fastest vdom libraries, such as Inferno, for updates, because they avoid a vdom entirely, and instead use reactive signals, which necessarily provide a slightly different end-user API than vdom libraries tend to. (This actually gives a mindful user even more optimization potential.)

[chinedufn]

@L1lith thanks for sharing lots of ideas, excited to have you around!

I agree with @qm3ster that transpilation would be out of scope, so I'm going to close this.

But I'd like to repeat that I really appreciate you coming to the table with your ideas!