The newest website frameworks1 keep referencing this thing called islands architecture. Which had me asking: what is an island? And how is it architected?
I think the motivation to create a new term can be explained by the context of how web development has progressed in the last seven or so years. React and its competitors exploded in popularity thanks to their features that greatly improved developer experience and capability: most notably the ability to build with Components and have UI automatically update to match a change in application state.
Frameworks like Next.js tried to fix this problem by using server-side rendering of React. Speaking from experience, marrying the two versions of your React code is not an easy task. You also still need to ship an entire framework’s worth of JS to add some interactivity to the page. In some (highly complex, highly interactive) sites this trade-off makes sense. In others: not so much.
This is not like building websites in 2011. Modern frameworks have picked up the authoring features made popular by SPA frameworks and figured out how to includes them in a system that still ends up serving HTML. So you can get a great developer experience while still building fast, accessible websites. Personally, I’m a fan.
As someone who builds a full-on web application, I’m interested to see how and if people use islands archicture frameworks to build their “intense” interactive applications. It seems like a no-brainer for blogs, documentation and other “content sites”. But what happens if you have 120 “islands” on your page? And all those islands need to know about eachother’s state? It may not be time to throw your SPA framework in the bin yet.