Hot Reloading and SSR replayability AND/OR State snapshot transfer

[atdiar]

Introduction

When reloading state (Hot/Live reloading, or Server-Side Rendering aka SSR), the logic for the dynamic mutations that can be applied to a webapp is handled via Wasm. One way to implement hot reloading and SSR is to record the chain of state mutation events and then replay them on the desired end-target.

Pros

• should be relatively easy to implement and should take care of hot reloading and SSR at the same time

  Cons

• Time and Space expensive

An alternative is to take advantage of the fact that Wasm is running in a sandbox on the client and potentially on the server as well. That means that the state of the program (stack and heap) could be transferred almost as-is from the server to the client. Although, it would probably require parametrization of the allocator by a given offset.

Pros

• since it is a snapshot, in the SSR case, it might be less expensive in terms of SPACE and subsequently TIME
• for the same reasons, should be faster and less error-prone than replaying state, although even replaying state might not be very prone to errors in the first place depending on the framework state management implementation

Cons

• more complex to implement than replayability?
• Not obvious that it helps that much for hot reloading wrt hydration which means that we would need replayability anyway. It would then be relegated to a performance optimization in the SSR case

[atdiar]

Replayability is in, implemented properly as far as I know, now. The other options require to be more low level. Could be revisited later if need be.