There are dairy products that last longer than many JavaScript frameworks. This statement accurately sums up the state of JavaScript in the last decade. Nevertheless, the JavaScript world has been rather stable for a while now. Three big technologies dominate the scene: Angular, React, and Vue. However, that does not imply that nothing is happening in the world. Recently, a number of new frameworks with innovative ideas have emerged. Some talk about a new wave of frameworks, others even about a new generation.

The following are some examples of this trend: Astro [1], Qwik [2], Marko [3], and SolidJS [4]. Even though these new frameworks do not even come close to having the same distribution as the major three, it is worthwhile to look at their ideas to gain a glimpse of the future of web development.

In this article, I will outline the new technologies, along with the issues they address and any implications. The first thing to do is to distinguish between different types of rendering.

The examples used, as usual, are available on my GitHub account [5], [6].

Client-side rendering in SPAs

In Single Page Applications (SPAs), all rendering is done on the client side, i.e., in the browser. This enhances response times and greatly improves usability.

However, since an SPA needs to load JavaScript bundles and data at startup, client-side rendering also delays programme startup. As a result, as figure 1 shows, some time passes before the First Meaningful Paint (FMP).

Fig. 1: Client-side rendering

The initial delay of a few seconds may not matter in business applications, because it is more important that the application works smoothly after the launch. It is a different story when it comes to public portals, where the focus is on conversion (the shift from interest to action). To keep bounce rates low, every millisecond counts.

In addition, search engines can still handle HTML better than JavaScript. That is why portals based on SPA frameworks usually use server-side rendering (SSR). Figure 2 shows the client-side rendering of SPAs.

Fig. 2: Server-side rendering

With SSR, the delivered HTML already contains all the information that makes up the page in question. The First Meaningful Paint (FMP) therefore takes place earlier. However, the page needs to load each JavaScript package separately in order to be interactive. They bring the static HTML to life. This is also called hydration. So that the JavaScript bundles do not have to reload the data that was already used in the server-side rendering, the server stashes it in an invisible area of the page, for example, in a script tag.

Although with SSR, the FMP takes place earlier, it takes longer to reach the so-called Time to Interactive (TTI) because it takes time for the bundles to load. The original HTML is now larger, which is another factor. Therefore, there is a period of time between FMP and TTI when the application seems interactive, but it is not. This is the so-called uncanny valley.

Solution: partial and progressive hydration

The renowned article "When everything's important, nothing is!" [7] highlighted the problem discussed in the last section back in 2016 and suggested progressive booting as a solution. The frameworks of the time, however, made it difficult to implement this procedure, which is now more commonly referred to as progressive hydration.

The idea behind this concept, that is meanwhile better known as progressive hydration, is that the page hydrates its individual parts gradually, i.e., progressively. As a result, the portion of the page that is currently visible can become interactive quickly (fig. 3).

Fig. 3: Progressive hydration...