Docs/tooling: publish browser-shipping constraints and data-tiering guidance #157
Description
Summary
Browser parity does not automatically mean browser-shipping viability for demanding applications. gametau should be more explicit about browser constraints and recommended data/resource strategies.
Why this matters
- Large or simulation-heavy apps can hit real payload, memory, and responsiveness limits in web builds.
- Honest browser guidance helps users design the right topology earlier.
- The project's web story becomes more credible when constraints are documented instead of implied away.
Suggested scope
- Document what browser support means in practice.
- Publish guidance for browser-safe data/resource tiering.
- Recommend when to prefer workers, streaming, chunking, or desktop-only/full-fidelity modes.
Topics to cover
- worker-first browser offload
- browser-safe resource/data tiers
- when web is a viable shipping target vs a parity/dev target
- how to think about large datasets and optional remote access
Acceptance criteria
- The docs include a browser constraints and strategy section.
- Guidance is concrete enough to influence architecture choices early.
- The browser story distinguishes parity from shipping viability.
- Related tooling/docs point users toward worker and data-tiering patterns where appropriate.