02 / ROUNDINGWELL
RoundingWell: a mature application moves to Marionette v5
RoundingWell upgraded a complex production application from Backbone.Marionette to v5, making refresh and cancellation lifecycles explicit while retaining its existing services and data.
An application already at work.
RoundingWell helps care teams organize workflows, worklists, forms, and follow-up. Its frontend is a substantial application used in daily work, with years of product decisions and an established browser-test suite behind it.
The migration preserved that investment while removing application jQuery and Marionette.Toolkit. Backbone data and routing, Handlebars templates, and the service layer stayed by choice; Marionette v5 does not require Backbone. Explore the application · Runtime integration
Refresh the results. Keep the context.
Change a worklist filter while a patient sidebar is open. The results need to refresh; the surrounding page and sidebar should stay in place. Navigate away, and unfinished work must lose permission to update the replacement screen.
The migration gives the page, results, and sidebar separate owners. The page coordinates its children; the results application owns selection, bulk editing, status, and list content. These boundaries give loading, refresh, and cleanup a specific home. Page composition · Results ownership
With Marionette v5, the application replaces its local request coordinator with prepareStart and retained restart(): the results container stays mounted while replacement data loads. This gives refresh and cancellation a standard lifecycle, with less application-specific coordination. Lifecycle source
Protect the workflow.
The application has an established browser-test suite for care-team workflows. The linked refinement scenarios check that cards remain during refresh, failed loads can be retried, and sidebar navigation stays available while data loads.
Those user-visible contracts give future changes something concrete to preserve. Read the loading scenarios · Verification record
What got faster?
A September 23 benchmark compared real worklist Views on v4 and v5 branches, using synthetic data and each branch’s actual templates, styles, and nested controls.
| Operation | v4 branch | v5 branch | Change |
|---|---|---|---|
| Render editable action cards | 244.5 | 186.3 | 23.8% less time |
| Filter out half the action cards | 60.6 | 9.4 | 84.5% less time |
| Destroy the action list | 62.4 | 43.8 | 29.8% less time |
| Reverse flow-card order | 104.2 | 109.5 | 5.1% more time |
Rendering, filtering, and teardown improved. Flow-card reversal became slightly slower because increased style/layout cost outweighed cheaper synchronous work.
These historical results used a v5 beta build and have not been rerun against the final migration. Timings include synchronous work and forced style/layout, excluding network and the full app shell. Application and adapter changes accompany the framework change, so these results cannot isolate Marionette’s contribution. All 92 comparisons and uncertainty ranges.
Give the next change a home.
RoundingWell’s migration shows how an established application can preserve useful product behavior while making ownership clearer. A sidebar change, loading state, or late-response bug has a specific place to investigate and a workflow to test.
For another mature app, start with one demanding workflow: decide what stays mounted, what refreshes independently, and who owns unfinished work. Preserve its behavioral checks, then measure its expensive interactions.
Evidence and methodology
Published by the Marionette project. The migration combined human direction and agent assistance; it was not a controlled agent-development experiment. Source links pin the initial migration and lifecycle refinement separately; loading scenarios use 870da88e24b7b14bf2563b3325199a4534c45aee. Paul Falgout, who also maintains Marionette, confirms that the v5 upgrade is deployed in production. Verification history is linked, not rerun for this article.
Benchmark: September 23, 2026 (Asia/Seoul), Apple M2 Pro, 16 GiB RAM, headless Chrome 153.0.8010.53, 1440 × 1000, unthrottled, warm caches. Exact package versions, source pins, and file hashes identify both benchmark builds.
Each configuration used 15 alternating branch pairs after two discarded warmups, with no outliers removed. The preserved data contains 360 measured sequences and 2,760 operation timings. Recorded assertions cover list behavior and teardown. An earlier run missing global design tokens was excluded. Exploratory bootstrap ranges describe local variation; cold startup, full navigation, mobile use, live APIs, paint timing, and memory retention were not measured. At 5,000 rows, rendering still took seconds on both branches.
Full method and limits · Complete summary · Raw 100–1,000-row samples · Raw 5,000-row samples. The table reads the preserved CSV directly. The hero pairs the RoundingWell and Marionette vector logos; the worklist image is a browser capture with synthetic data.