# Two hours. 1,738 edits. What we tested.

A fast edit is useful. A development session that stays reliable after hundreds of changes matters just as much. We ran a frozen PRNext 0.1.17 development snapshot for two hours to examine that longer workflow.

The aim was to find lost state, broken recovery, interrupted streams and uncontrolled resource growth. This was a stability test with a defined workload, not a new speed comparison against Next.js.

## A session with real edits and real browsers

The run lasted 7,201 seconds and applied 1,738 JavaScript and CSS edits. Four Chromium tabs exercised App Router and Pages Router fixtures. Intentional syntax errors interrupted the sequence 28 times to test recovery.

The browser checks retained a document marker and component state, rather than considering an HTTP 200 response sufficient. The workload also checked streamed response order and background work accessing the cache after the response.

The scenario also exercised 175 Server Action invocations. Each response had to belong to the expected application generation, rather than merely succeeding at the transport layer. Syntax recovery had to restore the page to usable output after the source was repaired, without resetting the state in unrelated tabs.

Four browser tabs, with preserved document and component state. 28 recoveries after forced syntax errors. 174 streaming and 174 background/cache checks. Zero page errors recorded by the browser harness.

## Measure the service tree, not just one process

The sampled process tree included Node.js, esbuild and the native Rust service. Its peak proportional set size was 536.51 MiB. Growth between the defined steady-state windows was 59.05 MiB, with at most ten sampled processes.

These readings stayed within the test’s resource budgets. They are observations for this fixture, sampling method and machine; they are not a universal memory requirement or a proof that no leak can exist.

Counting only the native service would hide the cost of the JavaScript workers and compiler helpers. Proportional set size also accounts for shared memory differently from a sum of resident-set readings. The peak and steady-state growth therefore belong with their sampling method when another run is compared with these numbers.

## Be explicit about the tested snapshot

The two-hour run used a frozen snapshot before the final .mts/.cts framework-boundary guard was added. Its edited sources were JavaScript and JSX. The final guard received separate regression, packaging and platform checks, plus a shorter four-tab smoke run.

An auxiliary filesystem-retention monitor also had a 25-minute sampling gap. The primary browser and memory checks continued. Keeping those limits in the report matters more than presenting an uninterrupted result that was never measured.

The distinction between snapshots is important for security-sensitive fixes. The later boundary guard has its own passing regression and lifecycle evidence, but those checks cannot retrospectively change the source that ran for two hours. Keeping both records makes it possible to understand exactly what each result establishes.

## What we take from the result

On this Linux x64 workload, repeated editing, recovery and resource budgets held up. Windows x64 received separate packaging, lifecycle and browser validation. Separate browser regressions also verify state preservation for anonymous default components and fresh Server Action responses.

It does not validate macOS or ARM64, replace application-specific testing, or show a new performance advantage over Next.js. Those are separate questions with separate measurements.

For an application-specific check, keep several representative pages open, interact with them before editing and include an intentional syntax failure followed by a repair. Observe browser errors and the service process tree alongside build duration. This tests continuity of work rather than reducing the whole session to its quickest refresh.

Published: 2026-10-24

Modified: 2026-10-25

Author: PRNext

---

Language: en

Canonical: https://prnext.dev/blog/two-hours-of-development-testing

Index: https://prnext.dev/llms.txt