Browser-first, Ruby-first
A four-part series on portable web standards, endpoint compute, recoverable offline data and safe Rails synchronization.
A browser can make an application useful on a modest device and a poor connection. The goal is dependable work: use shared web standards, make enhancements optional, save edits honestly and synchronize them without losing authority or history.
Here, endpoint resources means the user’s device: its processor, memory, storage and browser APIs. This series connects those resources to a Ruby-first application with server rendering, small adapters and explicit failure behavior.
One workflow across four parts
Use a field report as a running example: open an assigned report online, edit a draft on a train, validate a selected document locally, recover after restarting the browser, then submit when connectivity returns. Reading a public page should need little machinery; storing a draft and submitting an authoritative record have stronger requirements.
- Build on durable web standards
Choose a support policy, progressive enhancement and a repeatable compatibility review.
- Use the device thoughtfully
Move useful work to workers and optional runtimes with explicit resource budgets and fallbacks.
- Make offline work recoverable
Separate caches from user data, manage browser lifecycles and test storage failure and recovery.
- Synchronize safely with Rails
Design an outbox, scoped idempotency, conflicts and authorization around retryable operations.
Scope and evidence
These articles are engineering guidance, not a shipped offline runtime. Proposed protocols and code are illustrative unless explicitly marked as executed. Sources describe particular APIs and frameworks; browser support, permissions and lifecycle behavior must be tested for your application. No claim of universal platform support is made.
Our companion Ruby applications in the browser examines CRuby, WebAssembly and Rails packaging in detail. This series concentrates on cross-platform product behavior, device resources, durable local work and synchronization.
Keep the policy current
Review capabilities when adding a dependency, changing supported devices or shipping an update. Keep a dated support matrix and failure tests; retire a fallback only after reviewing who relies on it. Our testing guidance, service adapters and identity model remain the foundation.
Companion guide: Government accessibility, standards and Ruby connects accessibility requirements with design systems, Rails libraries and service-level assessment.