Skip to main content Accessibility Feedback

Reinventing the wheel for fun and profit

As a group, JavaScript developers seem to love to reinvent the wheel and then claim it’s a cool, new, original feature.

When Next.js let people create HTML on the server, people got really excited about how game changing it was. My dude, that’s PHP. It’s been around for ages.

When the folks at Basecamp confidently declared that HTML was an exciting new alternative to sending JSON and called it “HTML over the wire,” and JS devs fawned over their brilliance. Sending HTML over the wire? That’s, um… just how websites work?

And so of course, I found myself Rach Smith’s article on “islands” this week very interesting.

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?

Yep, it is!

Rach has a much more nuanced opinion on this than I do.

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.

I see this as the endless hype circle that front-end developers seem trapped in. Rach seems to view it as an evolution of the platform. I wouldn’t be surprised if we’re both right.

Either way, I’d encourage you to go give her full article a read. It’s quite good!