Last updates and information about this listThis list was created by Bastian from the Kirby Team on the Kirby Discord. For conservation purposes, I reproduced it here. It was then consolidated using Tom Mac Wright article about Single Page Apps replacements. Last updated September 25 2022.
JS-based page transitions
Using the history API and Ajax requests to fetch HTML of the next page and replace the current body with it. Basically emulating the look and feel of single page applications in multi-pages applications.
Inline replacement of components
Single Page Application (SPA)
The framework or library is loaded alongside the SPA code:
The framework or library compiles to the SPA and disappears:
"Meta" frontend frameworks
A single page application library gets extended to render or generate static "dry" pages as HTML on the server to avoid the initial long loading time, detrimental to SEO. Often comes with opinionated choices like routing, file structure, compilation improvements.
After the initial page load, the single page application code is loaded and attaches itself to the whole page to make it interactive, effectively downloading and rendering the website twice ("hydration"):
After the initial page load, the single page application code is loaded and attaches itself only on certain elements that needs interactivity, partially avoiding the double download and rendering ("partial hydration", "islands architecture"):
Non-hydration frontend frameworks
A server-side component-based framework or library gets data through API calls (REST or GraphQL) and serves HTML that gets its interactivity without hydration, for example by loading the interactive code needed as an interaction happens.
A client-side, component based application (Vue, React, etc) gets its state from pre-rendered JSON