# Static content, progressive interaction: choosing what needs JavaScript

How the JUMPHASH site separates readable content from interactive controls, and how to check its failure modes.

Source: https://jumphash.com/engineering/static-content-progressive-interaction/
Content owner: JUMPHASH
Updated: 2026-09-04

## Start with the information the visitor came for

A company description, product status or engineering explanation should be available when its document arrives. On this site, Astro generates the page text, links and metadata as HTML during the build. Interactive controls enhance that document separately.

Astro calls these independently hydrated components client islands. A component without a client directive can contribute rendered HTML without sending its component runtime to the browser. The decision belongs to each component, not to the page as a whole.

## Assign behavior deliberately

The portfolio table only displays public records, so it renders without hydration. The hash demo needs to respond to typing, so it hydrates on page load. The homepage contact form becomes interactive when visible. Decorative background work waits for browser idle time. Article pages do not need that background.

| Element | Needs browser behavior? | Reason |
| --- | --- | --- |
| Product text and links | No | Read and navigate using HTML |
| Hash input | Yes | Recalculate when the key changes |
| Contact form | Yes | Obtain a challenge and submit the inquiry |
| Decorative canvas | Optional | Visual presentation only |

## A failure between scripts still matters

Testing with all JavaScript disabled is useful, but it misses partial failure. A head script might run while a later script fails. If the head script marks the page as JavaScript-enabled and CSS hides content until a later observer reveals it, the page can remain unreadable.

The revised content styling leaves essential text visible regardless of observer state. Reduced-motion preferences and a pause control stop decorative motion; background canvas work also stops when the document is hidden. These are behavior choices, not a claim that every device achieves a particular performance score.

## Separate reading from successful submission

A readable static form is not evidence that a message was delivered. Form submission requires a valid endpoint, a usable anti-abuse challenge and a durable server acknowledgment. A direct email link gives visitors another contact path when the interactive path is unavailable.

This distinction also applies to robots and assistants. Public documents can be read without invoking the contact API. Access to public company information is not permission to submit a message or read private inquiries.

## Check the resulting experience

Inspect the generated HTML for the actual text, links, canonical URL and metadata. Then try normal JavaScript, no JavaScript, failed hydration, keyboard navigation and reduced motion. On representative pages, record measured LCP, INP and CLS rather than inferring them from the framework choice.

This article describes this site’s implementation and a verification method. It does not report a field-performance improvement, a search-ranking gain or a conversion experiment. Those require measurements from the deployed version and an appropriate observation period.

## Sources

- [Astro: islands architecture](https://docs.astro.build/en/concepts/islands/)

## Related

- [Internal study: one source for public product information](https://jumphash.com/work/public-information-pipeline/)
- [Explore the product directory](https://jumphash.com/products/)