Yeah, I'm not sure I understand why "islands" isn't just "bits of JavaScript on a static page".

It feels like the "JavaScript as a Server Side Language" folk are just repeatedly re-inventing stuff that has been done a million times by other systems with a different back-end only with a new fancy name.

▲

mpeg 14 hours ago | parent | next [-]

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.

▲

graypegg 14 hours ago | parent | prev | next [-]

It has been funny seeing the tide come in and out now a few times. Though I will admit that each time, the ergonomics get better. AJAX as a pattern was pretty gnarly if you wanted to do a bit more than update a notification badge or comment box.

There's a really nice pattern of using Custom Elements [0] for that sort of JS interactivity sprinkling. You can make your web application however you want, and when you want the client to run some JS, you just drop in `<my-component x="..." y="...">...</my-component>` with whatever flavour of HTML templating you have available to you. (also possibly with the is= attribute in the future [1], which will let you keep more of the HTML template out of JS)

It saves you the hassle of element targeting and lets you structure that part of your app a bit more without going overboard on "everything is a react component, even the server bits".

Want something "server side generated" in that JS? Just render it in attributes/body/a slot element/a template element, and expect to pick it up in the JS side of things. Feels like how it's supposed to be... and there's no framework required!

[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

	▲	WorldMaker 13 hours ago \| parent [-]
		Custom Elements do start to feel like the dream of the Knockout-era web of "Progressive Enhancement" is finally almost entirely out of the box in the browser. Especially ignoring the Shadow DOM and using Light DOM to style your unpopulated or static rendered fallback states as close to your "live" JS-driven state can lead to some very good experiences, including and especially when JS is disabled (or erroring).

▲

buu700 8 hours ago | parent | prev | next [-]

Here's a trivial example: https://supremecommander.ai. A raw CSS implementation of my blog's logo would have been a pain to build and maintain, but with Astro the code is relatively straightforward JS that becomes pure HTML/CSS at build-time.

The other nice thing is that you can throw all kinds of preexisting components from React/whatever into your site, and it will ship zero JS to the client until you explicitly flag a specific JS resource as an "island".

The only special thing about "islands" is that they're an escape hatch from the default behavior of JS being strictly build-time-evaluated. I found the terminology and description a little confusing at first too, because it makes it sound more special than it is. But the concept makes sense when you understand the context of Astro's intentional default behavior.

▲

weakfish 5 hours ago | parent [-]

Your website also reloads itself every 4 seconds for me on mobile Firefox

▲

buu700 5 hours ago | parent [-]

Good to know, thanks! I can't reproduce that on Android (and it's especially weird since the site has almost no JS), but I'll investigate and try to figure it out.

▲

weakfish 5 hours ago | parent [-]

Np! Hopefully my comment didn’t come off aggressive, meant it to be helpful

	▲	buu700 40 minutes ago \| parent [-]
		lol, well I'd appreciate the heads up even if it were meant to be aggressive, but thanks. Should be good now; the issue was most likely a CSS animation causing the browser tab to crash, so now it'll just turn off the animation whenever the page is quickly reloaded twice in a row. By the way, I'm getting a 404 at https://www.weakphi.sh/showcase.

▲

verdverm 14 hours ago | parent | prev [-]

The have Rust now so the entire tooling layer can justifiably be rewritten a few more times