A zero-JavaScript default belongs in the response
Fresh’s conditional bootstrap change makes a framework promise testable. Inspect scripts and preloads by page capability before claiming a script-free response.
By 
Paul. Languages and frameworks
A page without interactive components can still receive framework JavaScript. The phrase “zero JavaScript by default” becomes useful only when the delivered response reflects it. Fresh’s conditional bootstrap change gives that promise a concrete boundary: inspect what a page emits for the capabilities it uses. The absence of an island in source code is insufficient evidence about the browser’s response.
The Fresh 2.3 announcement, dated April 24, 2026, says earlier pages received a small bootstrap even without islands or partials. The change checks both capabilities before injecting it. Pull request #3696 was created on March 21 and merged on March 29. Those are implementation milestones, distinct from the April release announcement. This historical example establishes no version installed on a particular site.
Define the claim at page level
An island is one reason for a framework to initialize client behavior. Client navigation through partials (f-client-nav) is another. A page can omit the first while requiring the second. Describing every island-free page as script-free collapses those different capabilities into one convenient label. A useful default must state which capabilities can activate the runtime and what happens when none is present.
The resulting review unit is the individual page in its relevant state. A shared layout can add navigation behavior to a route whose content is static. A conditional component can change the requirements of an otherwise similar response. Looking only at the route’s own file can miss those dependencies. Follow the rendered composition far enough to explain the response the reader actually receives.
This does not require every page to have the same policy. A documentation page might use ordinary navigation, while an application screen might deliberately use client navigation. The important distinction is intentionality. The application should have an explanation for the capability and the output it requires. A framework slogan cannot replace that explanation for pages with different jobs.
Scripts and preloads belong in the evidence
The release describes a response without the framework’s script tag or module preload headers when neither capability is used. Those are separate things to inspect. Removing a visible inline bootstrap while retaining module preloads would leave a different response from the one described. A review which searches only for a familiar script filename can therefore miss part of the claim.
An application can also add its own scripts independently of the framework’s conditional bootstrap. Analytics, an embedded widget or a manually included module needs its own account. The framework can make its contribution conditional without proving that the complete document contains no JavaScript. Keep the claim’s subject explicit: framework output and total application output are related but different scopes.
For a future verification, compare a page without either capability against a page that uses an island and one that uses partial navigation. Inspect the delivered markup and headers for each. Record the application configuration alongside the observations so that another maintainer can repeat the check. This is a proposed check, not a report that such pages were built or measured for this article.
Separate output facts from performance claims
A missing bootstrap is an output fact. A faster visit is a measurement about a particular page and environment. Moving from the first to the second requires evidence about requests, caching and the user’s task. The change gives a reason to investigate performance; it does not establish a universal improvement in a business outcome or a particular site’s loading time.
This separation also helps a team decide whether a remaining script is justified. A small shared bootstrap may be a reasonable trade for uniform navigation across a product. Removing it could change the navigation experience which users expect. A team can choose that trade deliberately without pretending that every response has zero JavaScript. Honest naming supports a better decision than treating the smallest script count as the only goal.
The counterargument has limits too. Uniformity is a reason to keep a capability only where the product needs it. Applying the same runtime everywhere can be convenient for maintainers while doing little for a reader who follows a normal link. Discuss the concrete navigation requirement before making either a removal rule or an exception. The benefit needs an owner who can explain it.
Keep the promise maintainable
A useful acceptance condition describes observable output for a defined class of pages. For example, the class can exclude both islands and client navigation, while the check covers the framework’s script and preload contribution. That condition can survive a reorganization of components. It is more stable than a convention which assumes a particular directory will always contain static routes.
Changes to layouts deserve attention because they can alter many pages at once. Adding client navigation to a shared wrapper changes the capability account even if no article or documentation file changes. The review should make that consequence visible to whoever owns the page policy. Otherwise a default can drift while every individual change appears locally harmless to its author.
In a custom software project, specify the output requirement alongside the navigation requirement. Then choose the framework behavior which satisfies both, with an explicit exception where a shared runtime serves the product. Fresh’s historical change is valuable because it makes the boundary inspectable. The continuing responsibility is to keep each application’s claim aligned with the response it actually delivers.