Consider caching for JS code serialization (maybe an enum too)

[LiveDuo]

From: https://www.reddit.com/r/rust/comments/1i0hcrt/comment/m706d2x/

The method of serializing JS commands seems slow: it requires having a string of JS that scales O(n) with the size of the application or the individual change, which you need to generate on the WASM side (fine), do a bytewise copy of over to the JS side, and then have JS parse and evaluate (which is synchronous and blocking). Fine for smaller apps of course. But eventually you may want to consider having something like an enum of common DOM operations, and serializing those as bytes. (So, rather than sending .setAttribute("foo", "bar") as a string every time, you can send [0, "foo", "bar"] or whatever.) This has an even more extreme effect for things like your callback code, which is quite a bit of JS per callback. You will notice it if you ever try to do things like "create a table with 1000 rows with 3 click handlers per row". (You may already be doing this, and I missed it; if not, check out sledgehammer for inspiration, which is what Dioxus uses.)

I was considering something like this. Maybe, a low hanging fruit is to cache the DOM operations in JS and only send them once. So .setAttribute("foo", "bar") the first time and then [cacheId, "foo", "bar"] every time after. In regard to the enum I'd guess there's a big design space (big for the size of tinyweb :)). There's choice about which DOM operators to include in the enum and the overhead to go from JS code to enum in Rust and enum to JS code in javascript. A few benchmarks with different JS code sizes and different operations should shed some light and will be very interesting to see.

Relevant code: https://github.com/LiveDuo/tinyweb/blob/master/src/rust/src/invoke.rs#L163