Wtf is an island and why is it in my website?
The newest website frameworks1 keep referencing this thing called islands architecture. Which had me asking: what is an island? And how is it architected?
When I first read about how islands architecture works: the HTML for a page is rendered by the server and then sections (islands) of that page are made interactive via JavaScript, I was confused. Isn’t that just describing how we built webpages back in 2011 with jQuery?
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.
We got on the JavaScript-rendering train at CodePen, migrating our Rails and jQuery powered website to a React rendered one. We gained the ability to ship interactive features faster, but we lost the performance and accessibility of server-side rendering. If we screw up and bork the React rendering on the CodePen homepage, you’ll get a Black Screen of Death. It’s not great, but it was the trade-off you made to make a decent web application in 2017.
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.
Front end developers tried to do the client-side JavaScript framework thing, they tried the both-sides JavaScript framework thing, and now they’re back to server-rendered HTML with JavaScript on top. An ungenerous take would be to call this an idiotic circle where we’ve ended up back in the beginning, but that’s not what’s actually happened. And that’s why people are talking about “island’s architecture” now.
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.
Comments
TIm St.Clair
September 14, 2022 at 9:39 PM
I'm always amused by the cycle of server side rendering becoming client side rendering. I started the process back in the IE4 days when we realised that client-side rendering was a possibility (back then in a online-learning system). Users would need to fill in forms a lot and the full-page-refresh technique meant carrying a LOT of data over the wire - and back in those days the students were dialled in on 33k or 56k modems and the web app had hundred if not thousands of pages. Pretty poor user experience. So we 'islanded' portions of the page after its initial render: First we'd wait until the user interacted with a portion of a page (click), then using server side session states, databases and iframe/javascript based communication we'd render the users data as partial html complete with their saved data and send that back down the wire. Different areas of the page would either be aware of the state of other forms or interactive elements (e.g. the input in one might influence the output of another); or the pages were multi-user aware for live classroom scenarios. That system ran microsoft's ASP which COULD run javascript on the server, so we would develop code that could run both server and client side (lots of limitations, wasn't a great time, worked). As better client-side technologies have come along like the xmlhttprequest object, json and js libraries/frameworks we adapted to templating/rendering client side because it was pushing less data and the bandwidth was getting better. I think now people have forgotten the long legacy very-low bandwidth enforced on the web (and in many places around the world still exists) as shown by the disregard some frameworks and developers have for how much javascript gets sent to the client before the page can run. pushing 12MB of javascript over a 3G connection isn't fun for any involved. Now with this 'new' technique for rendering html at the server and sending that, it feels to me like we are coming back to the same point on the turning wheel of web development and calling it new.
Edward
December 18, 2022 at 10:25 PM
What next ? Realizing rendering javascript on the server makes you run through that sweet investor money 25 times faster and making a new programming language better for templating... something like... let's call it jhj
Leave a Comment
💯 Thanks for submitting your comment! It will appear here after it has been approved.