Vue Islands With a Job
A rule of thumb for using Vue islands in Astro only when readers need stateful interaction after the page loads.
It is easy to reach for a framework component out of habit. The component feels tidy, the props are typed, and suddenly a static list of links is shipping a runtime.
On this site, a Vue island has to have a job.
The Test
Before adding an island, I ask one question: will the reader change state after the page loads?
If not, an Astro component is enough. It still gives me components, props, and typed data while authoring, then renders to plain HTML.
If yes, Vue is worth considering. That test keeps the JavaScript budget tied to what readers do, not to what I am used to writing.
Two Islands Passed
Only two surfaces earned a Vue island:
- Search reads the query, waits for typing to settle, loads Pagefind, drops stale responses, and keeps the URL in sync.
- The portfolio galleries handle a carousel, autoplay, and an image viewer with zoom and focus management.
Both involve live input and changing state that would be awkward to coordinate without client JavaScript.
Several Did Not
Topic filtering looked like a candidate, but it only toggles a few rows, so it is a small plain script. The theme controls and More menus are plain scripts too, and the menus lean on native popovers for most of their behavior.
Keep the state with the interaction that needs it. A gallery can own its viewer and a search field can own its results without making the rest of the page carry a framework.