As a group, JavaScript developers seem to love to reinvent the wheel and then claim it’s a cool, new, original feature.
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?
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?