The web still needs readable pages. It also supports increasingly capable applications. A good architecture does not need to declare one dead in order to make room for the other.
The useful question is where each kind of work belongs.
Put authority near the data
Authorization, accepted prices, and durable mutations need a trusted execution boundary. They should not depend on a client being honest.
The browser can provide responsive previews and local interaction, but the server must decide which changes become authoritative records.
This boundary remains important whether the interface uses server components, islands, a client framework, or ordinary HTML.
Put interaction near the person
Pointer feedback and small local changes should not require a network round trip when they can be handled safely in the browser.
Keep the interface usable while remote work is pending. Explain which state is saved and which is still a local draft.
Offline behavior needs an explicit reconciliation policy. “Local first” is a design commitment about data and conflicts, not simply a cache setting.
Put expensive work where it fits
A worker can isolate CPU work from the main thread. WebAssembly can support suitable compiled libraries. GPU compute can accelerate some parallel workloads.
None removes the cost of data transfer, initialization, synchronization, or maintenance. Measure the complete path before moving work.
A small calculation may remain faster and simpler in ordinary JavaScript.
Preserve a readable product surface
Navigation, forms, error messages, and core content should retain semantic structure. Accessibility is harder when essential information exists only inside a canvas or generated visual.
AI-generated interface proposals need the same review as human-authored ones: clear controls, permissions, predictable behavior, and a useful response to failure.
A flexible renderer should not become permission to invent a different workflow every time a user asks a question.
Make hydration a product decision
Astro’s islands documentation describes selective client hydration: interactive components can load independently while surrounding content remains HTML. The useful architectural choice is which user action deserves a JavaScript startup cost.
For a configurator, render the specification, saved dimensions, and contact path first. Give the canvas a reserved size and an explicit loading state. Hydrate an immediately needed editor promptly; defer an optional scene below the fold until it approaches the viewport. A deferred control must still explain what will happen when the user reaches it.
Create a route budget with three measurements: initial HTML and assets, JavaScript needed for the first useful interaction, and work triggered by opening the advanced editor. Test each stage on a slow connection. Moving a large bundle to a later request improves the first stage only if the later interaction remains usable.
Draw the authority path for one mutation
Follow a single change such as accepting a configuration: local preview, submitted command, server validation, committed record, response, and reconciliation in the browser. Write down which revision each step refers to and who may reject it.
Repeat the flow with a stale catalog and an expired session. The interface should preserve an editable draft while clearly reporting that the server did not accept it. Do not display a success state merely because the local scene changed.
This small exercise often exposes a more consequential problem than framework selection: a visually responsive client with no reliable account of what was actually saved.
Make change observable
Version contracts between services and clients. Keep an asset manifest, test migrations, and record the environment that produced a result.
Observability should answer product questions: what failed, for whom, and what state was preserved? A large dashboard is less useful than a small set of reliable signals.
Choose the simplest stack that makes these boundaries clear. Add a technology when a measured need justifies the extra moving parts.
The frontier is not a list of fashionable libraries. It is the ability to make a more capable application remain understandable and dependable.
Keep a good idea close.
Follow Signal Tower
