> React makes sense if you're making Gmail.

Except the old Gmail used to be so much faster…

Many technical directions in the past 15 years have been a thinly veiled attempt to actually get paid for doing work.

> Users get by with it.

They would not if they had choice.

Vite + React is the go-to recipe.

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!)

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/...

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.

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