The key difference between islands and what we used to do back in the day (js on a static page) is that with an islands approach you architect your site with a components-driven approach where everything encapsulates the js/css/html it needs, then you mark it as an "interactive" island if you actually need client-side js to run – the code is the same, but it either runs only in the server (default) or in both server and client.

I know this sounds similar, but, compared to the more traditional approach, there is a certain simplicity to having everything just be javascript. You can often run the same libraries on both server and client depending on your needs, plus it fulfills the promise of web components in a way that is easier to work with (though WCs have also come a long way!)

▲

charleszw 14 hours ago | parent | next [-]

I will also say encapsulating everything you just said in a single term, "islands," is a lot simpler and prettier to discuss. At least from my perspective, the naming also makes a lot of sense. Literal islands of interactivity surrounded by an ocean of static.

▲

efilife 12 hours ago | parent [-]

the naming is backwards then. An island is static, an ocean is not. See how it is a buzzword up to your interpretation?

▲

aatd86 12 hours ago | parent [-]

now that you say it :o

Should be astro lakes or something.

▲

mpeg 10 hours ago | parent [-]

Islands is just a catchy name I guess. I always thought the markojs terms for it made sense, but are more technical / less catchy: they called it “full page hydration” -> everything needs to be delivered as js and “component level hydration” -> islands, only specific component sub-trees need to be hydrated.

Then “sub-component level hydration” would be resumability like in qwik where only events and their dependencies get serialised as client js.

	▲	aatd86 10 hours ago \| parent [-]
		Yeah. Well to their defense, it is probably to be understood as islands of interactivity lost in a sea of static elements. The term is definitely more evocative.

▲

dreadnip 13 hours ago | parent | prev [-]

You can do this with just about any programming language or scripting language that can render HTML on the server + plain HTML and JS. You could do this with PHP 30 years ago.

	▲	mpeg 10 hours ago \| parent \| next [-]
		Yes and no, php didn’t give you any tools to manage this, most people writing php sites back in the day (including myself) were writing js that was coupled to a specific markup yet was maintained separately. This didn’t scale well. Then along came libraries like mootools, knockout, etc all the precursors of react, then react changed the game around encapsulation of markup and code into one place, and straightforward data flow. SPAs were inefficient so server side rendering of js became ubiquitous, islands are a further optimisation of ssr. This hasn’t happened in a vacuum, if you look at modern php frameworks like inertia they have a lot more in common with Astro than they do the good old 90s php
	▲	s4i 10 hours ago \| parent \| prev [-]
		You could and yet nobody did. You need to give credit to a project like Astro that takes a pattern, popularizes it and makes it straightforward to adopt via a framework.