I've been fascinated by the "islands of interactivity" architecture popularized by tools like Astro, but wanted to see if we could achieve a similar DX and performance benefit without a build step or a Node.js server for rendering.
This post, "No-Build Client Islands," explores exactly that: bringing the island concept fully to the client side. We use native ES modules, Preact + HTM for component rendering, and Page.js for client-side routing.
The core idea is that your "static site" (the shell and routes) is rendered by the client after the initial HTML load, and then specific "islands" of interactivity are mounted on demand, much like Astro or Fresh – but all within the browser. This means:
- Zero build tools: No npm, Vite, Webpack. Just ES modules.
- Truly backend-agnostic: Serve static files from anywhere your heart desires (Go, Rust, Python, Java, or just a CDN).
- Tiny runtime: The core libraries (Preact, HTM, Page.js) are very small.
- Client-Side Rendering & Routing: Unlike Astro which does build-time generation for static parts, here the client handles the initial page structure and routing, then hydrates interactive islands.
Think of it as taking the best parts of the islands model (component-level interactivity, selective hydration) and applying them to a purely client-rendered SPA, aiming for maximum simplicity, stability, and longevity.
I'm keen to hear your thoughts on this client-side take on islands, how it compares to server-centric/build-time approaches for your use cases, and any potential pitfalls or advantages you see!
mozanunal•8mo ago
I've been fascinated by the "islands of interactivity" architecture popularized by tools like Astro, but wanted to see if we could achieve a similar DX and performance benefit without a build step or a Node.js server for rendering.
This post, "No-Build Client Islands," explores exactly that: bringing the island concept fully to the client side. We use native ES modules, Preact + HTM for component rendering, and Page.js for client-side routing.
The core idea is that your "static site" (the shell and routes) is rendered by the client after the initial HTML load, and then specific "islands" of interactivity are mounted on demand, much like Astro or Fresh – but all within the browser. This means:
- Zero build tools: No npm, Vite, Webpack. Just ES modules.
- Truly backend-agnostic: Serve static files from anywhere your heart desires (Go, Rust, Python, Java, or just a CDN).
- Tiny runtime: The core libraries (Preact, HTM, Page.js) are very small.
- Client-Side Rendering & Routing: Unlike Astro which does build-time generation for static parts, here the client handles the initial page structure and routing, then hydrates interactive islands.
Think of it as taking the best parts of the islands model (component-level interactivity, selective hydration) and applying them to a purely client-rendered SPA, aiming for maximum simplicity, stability, and longevity.
You can read the full post here: https://mozanunal.com/2025/05/client-islands/
I'm keen to hear your thoughts on this client-side take on islands, how it compares to server-centric/build-time approaches for your use cases, and any potential pitfalls or advantages you see!