A list of JavaScript frameworks

The way the web was initially envisioned was through separation of concerns: HTML is for structure, CSS for styles and JavaScript for interactivity. For a long time the server was sending HTML to the browser/client through templates populated with data from the server. Then the page downloaded CSS and JavaScript. Those two then "attached" themselves to the structure and acted on it through HTML attributes, and could then change its looks, call for more data, create interactivity. Each time a visitor clicked a link, this whole process would start again, downloading the new page and its dependencies and rendering it in the browser.

Last updates and information about this list This 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.

JavaScript enhanced HTML

Event handling/reactivity/dom manipulation via HTML attributes. Development happens client side, without writing JavaScript.

Inline replacement of components

Static HTML gets updated via web sockets or Ajax calls on the fly with small snippets rendered on the server. Development happens server side, without writing JavaScript. Most of the time a plugin or feature of an existing server side framework.

Single Page Application (SPA)

A client-side, JavaScript component-based (mixing HTML, CSS and JavaScript in a single file) framework or library gets data through API calls (REST or GraphQL) and generates HTML blocks on the fly directly in the browser. Long initial load time, then fast page transitions, but a lot of features normally managed by the browser or the server needs to be re-implemented.

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.

Opinionated full-stack JavaScript frameworks

Using existing frontend and backend stacks in an opinionated way to offer a fullstack solution in full JavaScript

Server-injected SPA

A client-side, component based application (Vue, React, etc) gets its state from pre-rendered JSON