What a published page actually runs

A published page here is finished HTML, rendered on the server. What a visitor receives, and what a search engine receives, is the page rather than an instruction to go and build the page.

The runtime is small on purpose

On top of that HTML sits a small script, on the order of three kilobytes. It is not a front-end framework and it does not take over the document. It exists to make the interactive parts work.

Which is what makes forms survive caching

The form element emits a real submit button and the runtime posts it. That is the reason a form keeps working with the page cached and no framework present. The rules attached to each field are evaluated in the browser while somebody types, and again on the server when the submission arrives, against one shared specification.

Availability is never baked in

Booking and ticket availability is fetched at runtime and never written into the cached page. It is a deliberate constraint: nothing on a published page should ever claim a seat is free when it is not.

What you give up

Very little, in practice. The trade is that a page cannot depend on client-side rendering to exist. In exchange it is fast, it is indexable, and the parts that must be correct are correct at the moment somebody looks.