Skip to content 2.0

Classification of JavaScript Frameworks

Author: Natalia Venditto

Date First Published: Wed Jan 04 2023

Classification of JavaScript frameworks by application rendering type

JavaScript frameworks can be classified by the type of application rendering they support. The most common types are:

Render strategy

  • Client-side (at runtime)
  • Server-side rendered (universal or isomorphic)
  • Static generation (at build time)

Excluding client-side rendering, that renders a very dynamic type of UI, the other two types of rendering are very similar. The main difference is that server-side rendering is done at runtime, while static generation is done at build time, and they both deliver static pages to the browser.

In order to make the content dynamic, to introduce for example personalization, we will need to do a post process that bootstraps JavaScript to the static pages. This is called hydration, and can also be classified as:

JavaScript boot up

  • Full hydration (full app bootstrap)
  • Partial hydration
  • Island architecture
  • Resumability

Application type (based on routing strategy)

  • Single Page App
  • Multi Page App
  • Hybrid App (SPA + MPA)

Single page applications are typically built with a client-side rendering strategy, while multi page applications are typically built with a server-side rendering strategy. Hybrid applications are a combination of both, and many times we find micro-frontends as the result of this combinations.

Application type (based on use of libraries, open standards and cloud technologies)

  • Static Web App
  • Progressive Web App
  • Functional Web App

Before we dive into details, let’s discuss a shift in architecture trends that influenced the creation of new generation frameworks.

Why the shift from client-side to SSG and/or SSR?

It feels like frontend development has been going in circles for a very long time. From concatenating all static assets to send them in huge files in one request, to bundling them and sending them in multiple requests. From splitting frontend code (typically HTML, JavaScript and CSS) into different files, to now inlining JavaScript ot CSS to the components above the fold to combining technologies in one file (JSX, TSX, etc). And I could go on and on…

The answer is simple: it’s all about performance. About user experience. About speed. And obviously, about avoiding end-user bounce and facilitating conversion.