| Why this can be great: - The dev experience is closer to the early days of PHP. - TypeScript, Preact out of the box. No need to configure build tools / deploys much faster. It's a pain in the ass to make these working at the same time and targeting both browser and server nowadays. - You can have interactivity without bolt-on client-side scripts that are different from other parts. - The code could be running on the edges. - I'm not sure what does the island based client hydration means, but sounds like Remix Many other frameworks could do some of them but not all (Ruby needs JavaScript/Turbolink, Next.js need to build then refresh, etc) |
The islands approach is different: pages are server rendered, but you can easily define islands of interactivity (like, say, an auto-complete search bar) where just enough javascript is sent to make those components interactive—and only when it's needed. You can control at what point exactly each component is made interactive: as the page loads, when the component becomes visible, when the user first interacts, etc. It's a great way to balance performance and rich interactivity. If the user never scrolls down to your photo carousel at the bottom of the page, the javascript is never requested.
If this sounds like what we used to do with say PHP & JQuery, you're not wrong. The difference here is we have the same javascript-based template logic and component model both clientside and serverside.
Some other projects adopting the islands pattern: https://iles.pages.dev - https://astro.build - https://slinkity.dev
More reading: https://jasonformat.com/islands-architecture/