Positive feedback from framework authors

[littledan]

We discussed Realms in the frameworks outreach group. See the minutes at https://github.com/js-outreach/js-outreach-groups/blob/master/frameworks/notes-2020-01-16.md#realms-and-ses . Framework authors were interested for several use cases, including testing and server-side rendering.

[caridy]

We have debated, and we have made many changes based on the valuable feedback channeled by @littledan, I'm closing this issue since there is no action items pending here, feel free to reopen if needed.

[littledan]

Maybe this should be reopened so that we could continue to collect framework feedback? Sounds like the feedback we have documented so far isn't sufficiently convincing for some.

[pzuraq]

One thing we discussed a while back that I meant to note here is that Realms could be useful for isolating certain types of global state for parallelism. Ember.js has been developing a pull-based reactivity framework that uses a global clock, similar to a vector clock, to assign versions to state as it changes. I discuss the way this works in detail in this blog post.

The reason this system works and is fairly ergonomic is because JavaScript is single threaded, and in a client, there is usually only one instance of a given application, which typically owns all of the state controlled by the clock. Because of this, we can safely share the clock globally with all of the state of the app (we do this using module scope currently).

However, we've run into issues in SSR with this approach. In SSR, you may be serving multiple requests at the same time, which usually means creating multiple instances of the application in a single Node instance for performance reasons. If these separate instances share the same clock, then they can interfere with each other, e.g. if one increments the clock, it could cause the other to think it needs to rerender again, even though it has not had a state update within its own instance.

Currently, the only solutions we've developed are to either isolate the applications more thoroughly with V8 isolates, or to actually thread through the clock manually so it is no longer shared globally. Manually threading the clock through defeats a lot of the ergonomic wins of this system, so we want to avoid that.

With Realms, we could potentially create a new Realm for each request being served, and create a new shared clock per Realm. This would provide the isolation we need while preserving the ergonomics of the system.

[Jack-Works]

I discuss the way this works in detail in this blog post.

I read your blog about TrackMap. I think it is possible to create a new Realm and replace the intrinsic Map with the reactive TrackMap. So the developer won't need to learn about what TrackMap is and automatically get the reactive map.

[leobalter]

@littledan I believe we resolved this part already and our next actions forward might be more specific.