Background
PR #880 adds parent-coordinated initialization for standalone DoenetML iframes (dom-order and viewport-first strategies, enableParentCoordination flag, initializeDoenetParentCoordinator()), addressing #874 (Active Calculus pages hitting 3.6 GB peak / 1.7 GB steady with many embedded activities). It stalled in April and needs a rebase.
The analysis since then (measured ~184 MB per embedded viewer: ~120 MB worker boot + ~54 MB realm/bundle parse) clarifies where coordination helps and where it doesn't:
- Coordination gates
renderDoenetViewerToContainer, i.e. core/worker boot + MathJax + React mount — the right target for the initialization stampede.
- It does not defer the per-iframe ~29 MB bundle fetch/parse (each iframe's script tag loads eagerly). Hosts still need lazy mounting (
loading="lazy" iframes, or conditional mounting in React hosts) for that part.
- The parent currently must load the full 29 MB standalone bundle just to call
initializeDoenetParentCoordinator() (COORDINATION.md quick start) — a heavy ask for a coordinator.
Proposed rescope
- Rebase onto current main.
- Ship the coordinator as a tiny standalone script (a few KB) so static hosts like PreTeXt can add coordination without loading the full bundle in the parent.
- Implement coordination natively in
@doenet/doenetml-iframe's parent components: the React package already owns and messages all its iframes, so React hosts (assignment-viewer, DoenetApps) should get viewport-first + capped-concurrency behavior automatically, with no cross-window registration protocol or opt-in flags.
- Replace strictly-serial initialization with a max-concurrent-boots cap (1–2): strictly serial is unnecessarily slow for pages of many small activities, while a small cap still prevents the memory/CPU spike.
- Document the interplay: coordination (boot order) + lazy mounting (bundle parse) + the bundle-size work are complementary layers.
References
#874, PR #880, #1436 (prop updates without iframe reload), assignment-viewer mounting issues (Doenet/assignment-viewer#35, Doenet/assignment-viewer#36).
🤖 Generated with Claude Code
Background
PR #880 adds parent-coordinated initialization for standalone DoenetML iframes (
dom-orderandviewport-firststrategies,enableParentCoordinationflag,initializeDoenetParentCoordinator()), addressing #874 (Active Calculus pages hitting 3.6 GB peak / 1.7 GB steady with many embedded activities). It stalled in April and needs a rebase.The analysis since then (measured ~184 MB per embedded viewer: ~120 MB worker boot + ~54 MB realm/bundle parse) clarifies where coordination helps and where it doesn't:
renderDoenetViewerToContainer, i.e. core/worker boot + MathJax + React mount — the right target for the initialization stampede.loading="lazy"iframes, or conditional mounting in React hosts) for that part.initializeDoenetParentCoordinator()(COORDINATION.md quick start) — a heavy ask for a coordinator.Proposed rescope
@doenet/doenetml-iframe's parent components: the React package already owns and messages all its iframes, so React hosts (assignment-viewer, DoenetApps) should get viewport-first + capped-concurrency behavior automatically, with no cross-window registration protocol or opt-in flags.References
#874, PR #880, #1436 (prop updates without iframe reload), assignment-viewer mounting issues (Doenet/assignment-viewer#35, Doenet/assignment-viewer#36).
🤖 Generated with Claude Code