Jason Miller

Frameworks like Next or Nuxt often render each page server-side, shipping HTML to the client, but then also send enough javascript and json data to the client to "hydrate" the page back into fully interactive components. The whole site, then, really acts as one large javascript app once fully loaded.

The islands approach is different: pages are server rendered, but you can easily define islands of interactivity (like, say, an auto-complete search bar) where just enough javascript is sent to make those components interactive—and only when it's needed. You can control at what point exactly each component is made interactive: as the page loads, when the component becomes visible, when the user first interacts, etc. It's a great way to balance performance and rich interactivity. If the user never scrolls down to your photo carousel at the bottom of the page, the javascript is never requested.

If this sounds like what we used to do with say PHP & JQuery, you're not wrong. The difference here is we have the same javascript-based template logic and component model both clientside and serverside.

Some other projects adopting the islands pattern:
https://iles.pages.dev
- https://astro.build
- https://slinkity.dev

More reading:
https://jasonformat.com/islands-architecture/

There's many reasons to have a JS compilation step:

- Still targeting legacy browsers like IE11

- Using React / JSX syntax

- Using TypeScript

- Using other brand-new JS syntax that hasn't trickled out to wider support yet

- Using custom JS transforms for libraries like `styled-components` (see this Next.js discussion thread for examples of the many different non-standard Babel transformations that people are using: https://github.com/vercel/next.js/discussions/30174 )

That said, the ideal target language version _is_ getting better. Jason Miller ( creator of Preact) has done a lot of research on both browser support for ES2017, as well as tooling to reverse-compile ES5-targeted published libraries upwards to ES2017 syntax again for improved bundle size:

- https://jasonformat.com/enabling-modern-js-on-npm/

- https://web.dev/publish-modern-javascript/

Check out the islands architecture info, or search around for info on partial hydration. It's similar to how things worked in the jQuery days--you serve up plain old HTML and have a JS function that runs on page load to attach all the event handlers (onclick, etc.) to your dynamic elements (i.e. 'hydrating' the static HTML into dynamic HTML + JS components). The thing with frameworks like Astro is that they try to automate and manage all of that hydration for you, which is nice because for complex sites with lots of different components it becomes a huge, error prone chore to manually wire things up.

edit: Island architecture background info: https://jasonformat.com/islands-architecture/

Discussions about website architecture become a lot more productive when you use Jason Miller's holotypes idea [1] as your starting point. "Holotypes" is kinda just a fancy word for the common top-level uses of the web. E-commerce, search, media player, etc. With that foundation it becomes obvious that SPAs make a lot of sense for some holotypes and a lot less sense for others. We waste time when we talk as if MPA or SPA is appropriate for all website architectures because neither are and never will be. The uses of the web are just too broad at this point.

[1] https://jasonformat.com/application-holotypes/

> Do you realise that you are talking of a really small minority of what these tools are used for?

I absolutely do realise that; but the author seems to ignore them altogether (which is a bit odd, given his normally commendable spirit of inclusion). Contrast this with Jason Miller's (another Googler, author of Preact) guide to different architecture decisions based on different product requirements [0]:

[0] - https://jasonformat.com/application-holotypes/