I don't see how this is any different from jquery style development from eons ago except instead of jquery you now use react components that can SSR a nonempty initial state. Which you could do before too, few people just cared enough to do the extra work.<p>Seeing buzzword labels on every little variation of age old techniques every other week is exhausting. This "Islands Architecture" is pretty much what everyone was doing before SPAs came along.
Interesting idea. What he's saying is that instead of rendering your single page webapp entirely on the client-side like React or have the user wait for the whole thing to be generated and sent over with server-side rendering, you can carve up the page into sections (islands) based on whether they contain more or less interactive/dynamic content.<p>Based on these sections, less interactive stuff like text can be rendered on the server and sent over while more dynamic stuff is in skeletal form until client side rendering occurs. This allows the user to see the most important stuff under the correct link first while waiting for any dynamic components to be loaded client-side. Definitely works for some types of SPAs, maybe product sites or social media, but for more complex webapps like scientific tools or presentation software this might not be the best fit.
For content heavy websites, the Jamstack approach seems to be the way to go: You've got a build step where static contents are rendered and anything dynamic works client side as a micro app.
This is essentially what the react team is proposing with their new server components: you have the server doing most of the heavy lifting and data loading, leaving the client-side code to focus on the dynamic add-ons. The RFC and video are well worth watching: <a href="https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md" rel="nofollow">https://github.com/josephsavona/rfcs/blob/server-components/...</a>