DEV Community: Eric L. Goldstein

Exploring Web Rendering: Server Components Architecture

Eric L. Goldstein — Wed, 22 Nov 2023 21:03:14 +0000

Holes. You’re about to read about holes. Like in the ground. What? Server components architecture can be a confusing topic, so we’re going to build on all the knowledge gained in this article series so far until this fundamental shift in application architecture makes sense. We’ve made it to the final entry in this series, so thank you for following along to the end!

Let’s recap what we’ve covered so far. The case for server-first rendering was made since the first article, but each blog post hopefully made an increasingly convincing case for why doing so is essential for good performance. Starting at the beginning with part 1 of the series, isomorphic JavaScript includes code that runs unchanged on both server and client. However, all components on the page require their code to be sent to the browser for hydration purposes. Thus, a non-trivial startup cost exists when initializing the application code to make the server-rendered HTML interactive and is manifested by stutters and missing interactivity until the JavaScript executes to completion; this phenomenon is known as the “uncanny valley”. As outlined in article 2, one way to reduce the startup penalty is to use partial hydration a.k.a. “islands” wherein the amount of code sent to the browser is reduced by only sending interactive component code. Another performance-enhancing option is to delay when hydration occurs; this is known as progressive hydration and was covered in part 3. Near-elimination of JavaScript can be accomplished with streaming HTML – covered in part 4 of this series – by server rendering all static components as-is and sending placeholder content for those in the process of performing an asynchronous action like data fetching. As each async response completes, a new HTML “chunk” is sent back to the browser to update the page contents with almost no JavaScript; this repeats until the page is fully built.

Combining the techniques from those 4 articles and adding some new ideas can lead to a unique application architecture known as server components; how this combination works will be covered after the upcoming explanation of server components mechanics. To be clear, “server components” and “server components architecture” are not the same thing. The former refers to a type of component used in a component tree, specifically the server-only variant. The latter refers to the overall structure and behavior of applications using new frameworks such as React Server Components. Despite the frontend ecosystem’s overwhelming focus on React Server Components, server components architecture is not just part of a new version of React. In fact, it is available in frameworks like Nuxt for Vue.js and SolidStart for SolidJS – documentation coming soon but its Solid Movies demo app using only ~16kB of JavaScript has code available using its experimental islands router as a stand-in for upcoming server components support. Rather, server components should be thought of as an architecture that further shifts the developer mindset from the traditional SPA client-first one started roughly a decade ago to a server-first one with unique abilities. For simplicity and relevance, React Server Components using Next.js 14 will be used for examples throughout the rest of this article.

The server components architecture consists of two component types: (1) its namesake server components and (2) client components. Before this new architecture, single-page applications relied on components that were rendered in the browser by default. Using server components reverses this trend because components are now rendered on the server by default. Additionally, server components are truly server-only meaning that they never render on the client. As a result, numerous benefits are gained related to data fetching, performance, security, and user experience. Data fetching and performance are improved because the rendering server is likely closer to its data source than most end user devices, so making multiple round trips to a database, for example, will occur more quickly between data centers than between a data center and a user’s browser. Also, the code needed to fetch that data remains on the server including any API keys and secret information, so the data architecture remains simpler and bundle sizes smaller. User experience is impacted greatly by performance, so improvements here clearly cause knock-on effects for UX due to less server response delay and less code in the browser as explained above.

Client components, on the other hand, are a bit of a misnomer: they are isomorphic and execute identically on both the server and client with the additional benefit that server components can send props directly to specific client components; this ability to do hybrid rendering with server-client prop exchange at arbitrary points in time is a unique advantage server components architecture has over islands architecture. Additionally, client components are effectively persistent islands so when navigating pages, the “static” parts of the page (outside the islands) are sent as an API response from the server then diff’d with the current client virtual DOM to output the final real DOM; see the figure below for a visualization. Note that React now has the ability to update page content by diffing not only locally-rendered DOM nodes but ones rendered and sent by the server in a special, JSON-like VDOM format as well.

Client components persist across page navigations despite the new page’s HTML coming from the server in the form of VDOM “JSON”

Now that the definition is better understood, why the focus on “holes” at the start of the article? In the component tree, the two types of components are used in mutually exclusive layers, so there is effectively a boundary between client and server components. A component with a “use client” directive as its first line of code means that that component is a client component, but that component is only a boundary if it causes the component type to change; in other words, it is the first child client component of a server component, so a “hole” is created in the component graph to signify that the server must wait for the browser to fill in that part of the component tree. A client component that is a child of another client component does not create a boundary because one was already created by one of its parents. Conversely, a server component that is a child of a client component means a server component boundary was crossed so a “hole” is created in the component graph here as well.

Server components architecture requires boundaries to be crossed when switching component types. Behold the donut “holes”.

An important restriction is that server components cannot be imported into client components. However, server components can be children of client components. Thus, to get around the restrictions, pass server components to client components as props; most commonly a server component is passed as the children prop.

Let’s build a simple example to more clearly show how this architecture works including nesting a server component inside a client component. To make this easier to follow, an open source repository was created to house this demo application for easier tinkering and learning. Imagine a basic blog setup that allows sharing the first paragraph of content on social media. This could all be done in a server component except for the needed feedback from the user about if and when to share. Thus, to use server components as efficiently as possible, we will use the architecture diagrammed below showing a root <BlogPost> server component wrapping a <Share> client component which has server rendered content directly passed to its children prop; notice the similarities to the diagram above as well especially when considering boundaries being crossed and how the client component contents are mostly rendered by a server component.

Notice the 2 boundaries crossed (“holes”) and how the <Share> component is mostly rendered by the server

Examining the source code of both components can further illuminate the behavior and mechanics of React Server Components with Next.js.

First the <BlogPost> server component:

// External Imports
import React from 'react';

// Internal Imports
import { getParagraphs } from '../../utils/content';
import Share from '../Share/Share';

// Component Definition
export default async function BlogPost() {
  const paragraphs = await getParagraphs();

  return (
    <article>
    {paragraphs.map((paragraphText, index) => {
        if (index === 0) {
        return <Share key={paragraphText}>{paragraphText}</Share>
        }
        return <p key={paragraphText}>{paragraphText}</p>;
    })}
    </article>
  );
}

Because BlogPost does not have a “use client” directive on its first line, it is a server component, so all rendering and data fetching occurs on the server. Additionally, React Server Components encourages the use of asynchronous components to promote colocation of rendering and data fetching, so the BlogPost component uses async/await to load paragraph data before rendering. Such a design typically introduces waterfalls into the network graph because the server has to pause during each network fetch. However, Next.js argues that waterfalls are mostly prevented because global fetch() is replaced with a Next-specific version by default so that all requests can be memoized. The getParagraphs() function is meant to mimic a call to a CMS or something similar, so once its data is returned, rendering can begin. The first paragraph is rendered to the <Share> component and all other paragraphs are rendered into basic <p> elements.

Then the <Share> client component:

'use client';

// External Imports
import React, { useState } from 'react';

// Local Functions
function shareContent(content) {
  alert(`Sharing content: ${content}`);
}

// Component Definition
export default function Share({ children }) {
  const [isPending, setIsPending] = useState(false);

  function onClick() {
    setIsPending(true);
    setTimeout(() => shareContent(children), 0)
    setTimeout(() => setIsPending(false), 100);
  }

  return (
    <p style={{ backgroundColor: isPending ? 'yellow' : 'green' }} onClick={onClick}>{children}</p>
  );
}

Starting with a “use client” directive signifies that <Share> is a client component. To help illustrate the lessons of this article as clearly as possible, this component is a simple approximation of what sharing content on social media could eventually look like without the implementation complexity. Specifically, a paragraph is shown with a green background when no sharing is occurring and a yellow background while sharing is in progress. Note the contents of the paragraph rendered by the component’s “children” prop coming from the <BlogPost> server component. In other words, <Share> is a client component whose contents are mostly rendered by the server. Within the onClick() function, the three lines of code change the background color to yellow, then use setTimeout() to wait for the next tick of the event loop to execute shareContent(), and finally wait 100ms to set the background color back to green. The reason for the two setTimeout() calls is to ensure background color changes occur independently from showing the alert() box.

Revisiting an earlier-mentioned topic, how can this series’ 4 previous article subjects be combined into the server components architecture? The architecture does introduce new innovations unique to what came before it such as the server components component type, but it does rely on previous ideas as a basis for its functionality. The first article in the series covered isomorphic rendering and hydration which is a requirement for client components to function. However, because server components execute entirely on the server with no client hydration, they have more in common with old school PHP server-side applications than they do with modern frameworks. Client components are more than just isomorphic components, otherwise application state would be lost during page navigation because new server rendered HTML would overwrite client component HTML. Instead, each client component root can be thought of as a persistent island wherein island state is preserved across page loads; part 2 of this article series covers partial hydration which is a prerequisite for such functionality. Progressive hydration covered in part 3 is an optional performance tweak during page load to delay hydration until a component scrolls into view or the browser is idle, for example; hydrating this way is optional with the server components architecture. Streaming HTML mentioned in part 4 of this blog series is also optional but is made more powerful with components rendered only on the server. Older application architectures had two options for server rendered components: (1) a server-only application with no hydration or interactivity leading to a poor user experience, or (2) an isomorphic application with controlled interactivity and better user experience but hydration potentially reducing initial interaction performance. Streaming HTML with the server components architecture allows further refinement by choosing whether or not hydration is combined with streaming at a component rather than application level by streaming with <Suspense> within server or client components; thus, more fine-grained control over behavior, performance, and bundle size is allowed. Overall, while not all strictly required, the 4 previous article techniques – isomorphic rendering, hydration, partial & progressive hydration, and streaming HTML – are foundational to understanding server components architecture.

Somehow this 5-part, performance-focussed learning adventure has reached an end, and I could not be more thankful for you hanging in there to the end! I certainly hope you learned something new. If you have any questions or feedback about this topic or any others, please share your thoughts with me on Twitter. I would certainly enjoy hearing from you! And be sure to check out Babbel’s engineering team on Twitter to learn more about what’s going on across the department. Keep exploring!

Exploring Web Rendering: Streaming HTML

Eric L. Goldstein — Tue, 18 Jul 2023 17:37:35 +0000

Photo by Kylir Horton on Flickr

Welcome back to the 4th article in this performance-focussed series about web rendering; we’ve come a long way in a short time, so thank you to those following along. This discussion began with client-side rendering (CSR) and has progressed to and encouraged server-side rendering (SSR) for performance reasons. Remember that the server is the key to this strategy because using it to render eliminates the need to use JavaScript in the browser to do so. As discussed in part 2 of this series about islands rendering, the rapidly-growing performance divide between midrange and premium phones over the past 10 years signifies that faster hardware can no longer be relied upon for better performance. Rather, execution efficiency must be improved, and the most expensive asset download per byte is JavaScript. Thus, minimizing JavaScript’s use is key to good performance as the previous articles in this series have explained.

In an attempt to prevent any terminology-related misunderstandings, “streaming” is a common term most typically associated with audio and video. However, streaming HTML is an unrelated, text-based technology focussed on delivering content to the user as quickly as possible. While both can be accomplished in a browser, the latter is the focus of this article.

Streaming HTML is a very different concept from the hydration-based topics explored in this series so far. Let’s begin our investigation by providing a short history, a general definition, and an abstracted example before diving into the details. Back in 1994, Netscape Navigator 1.0 beta was introduced with a feature called progressive HTML rendering that allowed response HTML to be periodically flushed to the browser in “chunks” until the response was complete. In fact, HTTP 1.1 later added official support for doing so named chunked transfer encoding wherein a stream can transfer multiple chunks hence the name “streaming”. Effectively a modern rename of the same concept, streaming rendering uses a single HTTP response to incrementally server render a page’s HTML while minimizing the amount of JavaScript used. More specifically, the initial streaming response contains static content for data-independent components and placeholder content when waiting for data to be returned. In the meantime, the HTTP connection is held open while the server waits for its data requests to complete. Each bit of response is subsequently streamed to the user’s browser as soon as it’s ready, then its respective placeholder HTML is replaced, and finally the connection closes when all data requests are complete. Conversely, traditional server rendering waits for a page’s full output to complete including all data requests before any response begins; most server-rendered web pages load this way.

To provide some additional clarity, consider a dinner analogy with a customer, dinner table, waiter, kitchen, and plates of food. The customer orders 3 plates of food A (red), B (green), and C (blue) from least to most time consuming to prepare, respectively. With traditional server rendering, the waiter will wait for the kitchen to complete all 3 plates before returning them all to the table at once. Specifically, using the image below, step 1 shows plate A as complete but must wait in the kitchen. Step 2 shows plate B gets completed next followed by step 3 which shows plate C being finished last. Not till step 4 do all the plates leave the kitchen at once to be brought to the dinner table. Notice that no plates can leave the kitchen individually; the inverse is the main enhancement that streaming rendering enables.

Traditional server rendering requires all plates to be complete before being served

Conversely, streaming allows the waiter to bring each plate to the table as the kitchen completes it. Specifically, step 1 shows plate A as ready to be served. By step 2, the customer receives plate A at their table at the same time the kitchen completes plate B. Similarly, for step 3, the waiter brings plate B to the dinner table as plate C is completed. By step 4, the waiter has brought all 3 plates to the customer’s table. Clearly the customer can start eating more quickly in the streaming example; I know which waiter I would rather have!

Streaming rendering allows each plate to be brought to the table as it is ready

Streaming responses can occur in one of two ways: (1) in-order and (2) out-of-order. As the name suggests, in-order streaming delivers HTML to the browser in the same order as authored; this means that only HTTP is required but no JavaScript! For example, if 3 data requests are needed to build the output for a page and the first request is the slowest, that first request must complete and have its HTML returned before each remaining data request has its content delivered to the page; this is a similar problem to the traditional server rendering plates example above, specifically forcing completed data requests to wait before being served. Out-of-order streaming may unfortunately require a tiny bit of JavaScript in the browser to render each chunk of HTML, but immediate response after each data request completion is a huge advantage; thus most modern frameworks including React use this method. More specifically, each placeholder is rendered with an identifier, and each content chunk is followed by a tiny bit of JavaScript used to find the respective placeholder ID then replace the HTML with the new content; the following code example will show this in detail.

Now that the fundamentals are understood, a real-world approximation of React behavior follows in order to better illuminate the details. Using the <Suspense> built-in component in combination with rendering via renderToPipeableStream (Node.js) or renderToReadableStream (other runtimes) allows full out-of-order streaming support. Loading user-specific data from a database can often be a source of latency, so assume a demo homepage application with static content and a dynamic user profile dropdown if a user is logged-in. Specifically, <HomepageLayout />, <Carousel />, <Offers />, and <LearnMore /> components all output static HTML whereas our <UserProfile /> component returns dynamically-built HTML based upon data fetched from a database. The application could be structured like this:

<HomepageLayout>
  <Suspense fallback={<LoadingSpinner />}>
    <UserProfile />
  </Suspense>
  <Carousel />
  <Offers />
  <LearnMore />
</HomepageLayout>

React will render this top-down, so first it will render the <HomepageLayout> layout component and its children – all of which are the remaining components to render. First of these children is the Suspense boundary around <UserProfile />. Fallback component <LoadingSpinner /> is shown because <UserProfile /> data is being fetched on the server. Next, the <Carousel />, <Offers />, and <LearnMore /> components render their static content in order. Finally, because all components have rendered once, the component tree in the browser looks something like this (changes from one code block to the next are surrounded by “START CHANGE” and “END CHANGE” HTML comments):

<HomepageLayout>

  <!-- START CHANGE -->
  <div id=”suspense-placeholder-1”>
    <LoadingSpinner />
  </div>
  <!-- END CHANGE -->

  <Carousel />
  <Offers />
  <LearnMore />
</HomepageLayout>

Once the data is fully fetched on the server, the remaining HTML for the <UserProfile /> component streams to the browser at the end of the DOM:

<HomepageLayout>
  <div id=”suspense-placeholder-1”>
    <LoadingSpinner />
  </div>
  <Carousel />
  <Offers />
  <LearnMore />
</HomepageLayout>

<!-- START CHANGE -->
<!-- begin UserProfile HTML -->
<ul>
  <li>menu item 1</li>
  <li>menu item 2</li>
  <li><button type=”button>Logout</button></li>
</ul>
<script type=”text/javascript” id=”suspense-render-1”>
  const suspenseRender = document
    .getElementById(‘suspense-render-1’) // Assume this works
    .previousElementSibling;
  document
    .getElementById(‘suspense-placeholder-1’)
    .replaceWith(suspenseRender);

  // Hydration code here...
</script>
<!-- end UserProfile HTML -->
<!-- END CHANGE -->

When the synchronous suspense-render-1 <script> gets executed, the <UserProfile /> HTML gets copied into its correct placement then is hydrated:

<HomepageLayout>

  <!-- START CHANGE -->
  <ul>
    <li>menu item 1</li>
    <li>menu item 2</li>
    <li><button type=”button>Logout</button></li>
  </ul>
  <!-- END CHANGE -->

  <Carousel />
  <Offers />
  <LearnMore />
</HomepageLayout>
<!-- begin UserProfile HTML -->
<ul>
  <li>menu item 1</li>
  <li>menu item 2</li>
  <li><button type=”button>Logout</button></li>
</ul>
<script type=”text/javascript” id=”suspense-render-1”>
  const suspenseRender = document
    .getElementById(‘suspense-render-1’)
    .previousElementSibling;
  document
    .getElementById(‘suspense-placeholder-1’)
    .replaceWith(suspenseRender);

  // Hydration code here...
</script>
<!-- end UserProfile HTML -->

The final HTML in its desired location remains with full interactivity after hydration. The <script> tag can be effectively ignored because it is done executing.

After reviewing its fundamental and practical aspects, streaming rendering can still be better understood by evaluating its pros and cons.

Streaming rendering provides numerous benefits over traditional server rendering. Moving data fetching and rendering to the server typically involves a latency penalty because both must fully complete before a response can be sent. Streaming eliminates this restriction by allowing fallback UI elements to be rendered in place of data-dependent components until the latter can be delivered to the browser. Furthermore, as in the React example above, HTML chunks can be delivered in any order with out-of-order streaming and a tiny trailing JavaScript payload to swap the HTML into its final location. In addition to the numerous performance benefits outlined by this series, client-rendered applications enjoy security benefits by doing data fetching and rendering on the server because vendors, technologies, and API tokens are hidden away from prying eyes. And streaming applications can often feel as fast as client-rendered ones if delivered using edge rendering – using the servers around the world and closest to your users to deliver dynamic content similar to a Content Delivery Network (CDN).

Streaming has a few downsides. Once a response begins and a response code is chosen (e.g. 200), there is no way to change it, so an error occurring during a data fetch will have to let the user know another way. Also, not all frameworks and runtimes support streaming, so choose carefully. Marko was one of the first (2014!) JavaScript frameworks to support streaming, and React and SolidJS both have great support for streaming as well, for example.

Our streaming journey has come to a close, so I hope it was enjoyable and enlightening! If you have any questions or feedback about this topic or any others, please share your thoughts with me on Twitter. I would certainly enjoy hearing from you! And be sure to check out Babbel’s engineering team on Twitter to learn more about what’s going on across the department. The next and final article in this series will truly be an epic endeavor when we explore server components! They’re not just for React…

Exploring Web Rendering: Progressive Hydration

Eric L. Goldstein — Mon, 03 Jul 2023 20:43:40 +0000

Photo by anthony kelly on Flickr

As we reach the third article in this series focussed on exploring web rendering and performance, welcome back! Opportunities for performance improvements are really becoming apparent, so I hope you enjoy what’s coming up. If you have any questions, feel free to reach me on Twitter and I’ll do my best to help. As mentioned in the previous article about partial hydration a.k.a. “islands”, 2 main options exist to more quickly make a page interactive: (1) do less work by only hydrating interactive components and ignoring the rest, or (2) hydrate in the future; the former was covered in the previous article while the latter is the subject of this article and is known as progressive hydration.

With traditional hydration during page load, an undesirable race condition known as the “uncanny valley” can occur when components are visible but not yet hydrated and thus non-interactive; progressive enhancement – using native HTML primitives such as forms as a fallback mechanism until JavaScript loads – is a typical remedy because eliminating this loss of interactivity before hydration is very difficult otherwise. However, progressive hydration delays hydration on purpose, so care must be taken so the user doesn’t wait when attempting to interact with the page. This is truly a delicate balance between minimizing performance impact and ensuring a good user experience. If done correctly, hydration will not be noticed by the user as it happens, but he or she will benefit from it.

A key reason why the progressive hydration portion of this article series comes after partial hydration (a.k.a. “islands”) is because they are often used together. Remember the goal of islands is to improve performance by limiting the number of components whose code is sent to the browser; interactive components can be thought of as islands of interactivity and only that code need be downloaded. Without the ability to break an application into individual hydration targets, the only way to progressively hydrate is to do so for an entire application which would effectively be opting into uncanny valley behavior and potentially, purposefully breaking interactivity; this is certainly a good way to frustrate your users! Instead, if some islands are hydrated immediately and others later on, the aforementioned delicate balance is restored and a better performance profile at page load will result.

How long do we wait to progressively hydrate? Luckily good patterns have been established by popular frameworks like Astro and Eleventy. Waiting to hydrate when a component scrolls into view or when the browser is idle are the options that will likely show the benefits most clearly; using Astro, the client:visible and client:idle directives correspond, respectively. For example, a <Carousel /> React component can be hydrated when it scrolls into view by writing it as <Carousel client:visible />; that’s it! The beauty of progressive hydration is that even if those established patterns don’t meet your needs, any time or event can be chosen as a target, but you’ll likely have to write your own code to do so. To make the process easier, Astro added the ability to add custom hydration directives in version 2.6, so check it out if you’re interested.

To emphasize the point of how useful partial and progressive hydration can be when used together, let’s reexamine the example from the previous article but this time with an overlay showing the boundaries of what’s rendered on screen (a.k.a. the browser viewport).

The previous article’s island-based component structure relative to the browser viewport

Three islands of interactivity exist on this page corresponding to the colored boxes: (1) the Shopping Cart component, (2) the Buy Now Button component, and (3) the Product Reviews component. From a user interest perspective, the Buy Now Button component is in the center of the screen so is likely to get the user’s attention first, and the Shopping Cart component is also on-screen and related especially if that button is clicked. However, the user can’t see the Product Reviews component at all. From an optimization perspective, progressive hydration can be used to delay execution of the Product Reviews component code until it scrolls into view; maybe the user won’t scroll down to it, so why bother? Using Astro’s syntax as a guide, let’s add a directive to the component and render it as <ProductReviews client:visible /> to see how this decision changes the performance profile of the page:

Progressive hydration prevents eager download of the Product Reviews component code

The Product Reviews component box is now white meaning that HTML is effectively static until the user scrolls it into view. Assuming these colored components all have a similar weight, approximately 33% less code runs during hydration at page load; pretty nice improvement for typing a few extra characters!

Progressive hydration provides numerous benefits over eager hydration methods. The initial page load will be less impacted by hydration bottlenecks because less JavaScript code will execute. This benefit can be compounded for non-urgent components by not even downloading the code for the component until hydration needs to occur. In other words, application bundle size will be reduced while improving Time to Interactive – the elapsed time from a page load beginning until user input can be quickly and reliably responded to. However, the delicate balance between immediate reaction to user action and minimizing code download and execution will need to be weighed to best determine the correct choice for each case.

A proper evaluation would not be complete without also examining the drawbacks of progressive hydration. The largest concern is the potential loss of user interactions due to missing JavaScript code pre-hydration. This can be mitigated somewhat by capturing user events such as clicks and keystrokes and replaying them when hydration has completed, but this comes with its own complexities and race conditions that are outside the scope of this article. Without a framework like Astro or Eleventy that includes handy directives to make delaying hydration easier, progressively hydrating requires a solid understanding of web APIs like IntersectionObserver and requestIdleCallback; for example, Astro’s client:visible and client:idle directives use those APIs under the hood, respectively. Thus, progressive hydration without a user-friendly framework is probably not a good choice for inexperienced engineers or teams.

Now that progressive hydration’s pros and cons are understood, what are the recommended ways to try it? At the risk of being repetitive, Eleventy and Astro have improved the developer experience significantly in this area, so the recommended way to learn is to start with either tool to gain experience. If more granularity is desired, build on top of either framework’s primitives or eventually build your own once the concepts are mastered.

I hope you enjoyed this overview of progressive hydration. If you have any questions or feedback about this topic or any others, please share your thoughts with me on Twitter. I would certainly enjoy hearing from you! And be sure to check out Babbel’s engineering team on Twitter to learn more about what’s going on across the department. Stay tuned for part 4 about streaming rendering and how full page loads can act similarly to a single-page app but without most of the JavaScript: magic!

Exploring Web Rendering: Partial Hydration (a.k.a. “Islands”)

Eric L. Goldstein — Tue, 13 Jun 2023 21:59:22 +0000

Photo by tiarescott on Flickr

Welcome back to the second part of my series focussed on exploring interesting and useful web rendering technologies. As the series progresses, you’ll notice a core theme of performance optimization by moving from client-first to server-first rendering. In fact, the reason for the ordering of these articles is to progress towards as little browser JavaScript as possible while maintaining interactivity. Starting from a traditional client-rendered single page application, if you follow these techniques in order, you can end up with far less JavaScript sent to the browser than when you started. As a reminder, when optimizing for performance, less application code means less to download and execute in order to accomplish the user’s intent. Considering the accelerating divergence between high-end and mainstream phones over the past 10 years as shown in the graph below, hardware is providing meaningful performance improvements only on expensive devices. Thus, as time goes on, making applications with efficient resource usage is becoming essential to guarantee a good user experience for most users because common devices are not getting noticeably faster. Remember: JavaScript is primarily a single-threaded language by design, and threads execute on cores.

From Alex’s Russel’s talk The Global Baseline, 2022 @ performance.now() 2022

As discussed in the previous article in this series, hydration initializes an application by adding interactivity to server-rendered HTML. Doing so can cause serious performance problems due to the entire application needing to render before becoming interactive; long tasks, UI stutter, and even pauses can be consequences of this heavy-handed initialization strategy. There are two effective ways to tackle this problem: (1) do less work when hydrating by skipping the portions of the DOM that will never be interactive (a.k.a. “partial hydration”) or (2) do hydration at some point in the future (a.k.a. “progressive hydration”); only the former will be the focus of this article, then the latter will be covered in part 3 of this series.

Before examining its details, partial hydration will be best understood by first exploring its origins to appreciate how we arrived at where we are today. The concept first arose with the Marko framework by eBay back in 2014 with a feature they now refer to as “Code Elimination” on their homepage. eBay’s motivation for creating a framework like Marko is clear once you realize the direct correlation between performance and revenue and the lack of sufficient JavaScript ecosystem options at the time to meet their performance needs. In fact, their timing is interesting because Marko is one of the first examples of a full-stack, server-first JavaScript framework, a clear indication of how important this design philosophy is to performance optimization because of the scale at which the framework has been operating since then. If you’re interested in more details about eBay’s motivations for creating Marko, Ryan Carniato – creator of SolidJS and previously a Marko core team member – wrote an article What has the Marko Team Been Doing all These Years? that delves deeper.

Where did the modern “islands” naming come from? The idea of “component islands” was named by Katie Sylor-Miller – frontend architect at Etsy – back in 2019 and expanded upon by Preact creator Jason Miller in his blog post entitled Islands Architecture. Within it, he explains how “islands” can be thought of like independent single page applications wherein top-down rendering is not required for the full page output to be built. Rather, each island is an isolated unit, so any potential performance problems in one “application” do not affect any others. A side effect of combining many single page apps (SPAs) onto a single page is that client side routing is lost because they all cannot control the browser’s URL, thus the application must be a multi-page app (MPA) with full-page reloads; stay tuned for part 5 of this series for how server components help solve that problem. He continues to explain that because the full HTML is returned to the browser, SEO and accessibility benefit because web crawlers and assistive technologies inherently understand the semantics of static HTML better than a dynamically changing DOM. Navigating with <a> tags allows assistive technologies to understand how to move between pages using the semantics of HTML instead of needing to reinvent the wheel with custom components and JavaScript in order for a11y technologies to understand navigation; no JavaScript is used as a result which is a performance win.

Now that the history is understood, onto the main topic: what is partial hydration? Let’s compare it to full hydration to make the behavior more clear. Remember, hydration usually occurs after loading a full page of HTML. Let’s use the diagram below as a visual aid wherein the largest white box represents the whole page and each white, red, green, and blue box represents a component; the non-white boxes are interactive components a.k.a. islands. Imagine a server preparing what JavaScript to send, then draw a box around each component that needs its JS sent to the browser. The full hydration case is quite easy: every component will have a box around it, so all code gets sent to the browser. According to the diagram, all 8 components’ code should be sent including:

Nav Bar
Shopping Cart
Product Image
Buy Now Button
Product Description
Product Reviews
Related Products
Footer

Each box is a component. Island areas filled in color, static areas outlined in white.

Partial hydration should include only interactive components and their children. Specifically, draw a colored line around only the interactive components on the page; the diagram above shows exactly this, and if you squint a little, they look like islands of interactivity hence their name. Now only 3 components’ code should be sent including:

Shopping Cart
Buy Now Button
Product Reviews

With partial hydration, only ⅜ or 37.5% of components have their JavaScript sent to the browser! The smaller your islands, the bigger the benefits because the ultimate goal is minimizing the amount of JavaScript sent to the browser as evidenced by myriad articles on the subject. Because server-side rendering (SSR) is used, the non-interactive component code is never sent to the browser because it would never serve a purpose: if that HTML remains static, why send code that will never change it? Instead, only code for the interactive islands is sent which has been shown to reduce the amount of code sent to the browser. As a result, less code is downloaded, parsed, and executed, so Time to Interactive is minimized by running less code that delays the user’s ability to interact with the page; in other words, users can click that Buy Now Button more quickly which increases the chances of a sale.

Partial hydration provides numerous benefits over traditional hydration. Less JavaScript required for an identical amount of interaction has no downsides aside from requiring MPA navigation; streaming rendering (part 4 of this series) and the full-page load portion of the View Transitions API (animations are fun!) can help hide the additional delay from an MPA navigation, but the loss of application state on page change should remain a concern. Using islands, faster page loads will result which will make users happier and push your pages higher in search rankings. Furthermore, less code is shared between server and browser, so the mental overhead required for dual-mode rendering in isomorphic rendered applications disappears for static portions of the app because those regions only run on the server; read part 1 of this series for more on how mental overhead can affect isomorphic application development. A further benefit is parallel loading of island code because each island is completely independent, so each island can hydrate as soon as it’s ready. Page load performance can be further improved by delaying hydration of some or all islands into the future; the specifics of this are detailed in the following article in this series (part 3) about progressive hydration.

Unfortunately partial hydration has some drawbacks as well. The first and most obvious is requiring full-page reloads during navigation; server components are effectively persistent islands which can mitigate this and will be covered in part 5 of this article series. Traditionally, partial hydration was very difficult to set up. You effectively needed to design a build process that dynamically created multiple render roots for multiple component trees and the ability to pass props to each one independently in addition to being able to share state between them. A good example of this is Markus Oberlehner’s terrific overview of this process in his blog post entitled Building Partially Hydrated, Progressively Enhanced Static Websites with Isomorphic Preact and Eleventy. The process he describes is very manual and was written before the advent of modern islands solutions included in frameworks like Astro. Additionally, state sharing between islands is made more complex than a traditional context-based design because there is no shared component root. Luckily, however, signals and signal-like libraries have been developed that can tackle this problem very efficiently and effectively; some libraries such as the Astro-recommended Nano Stores are less than 1 kB! Thus, whether this is truly a problem is a matter of perspective.

After all this promise of performance improvement, how can partial hydration be used today? The easiest and most flexible option is Astro because you can not only choose from a variety of frameworks for your islands like React, Preact, Vue, and SolidJS, but you can even mix-and-match different frameworks in islands on the same page! It even supports deployment adapters for serverless and edge rendering platforms too with only a few line changes necessary in your config file. If you’re a fan of Deno, the Fresh framework has great support for islands as well. The most-performant but least well-known option is Marko, especially the upcoming Marko 6 release whose compiler optimizations and support for resumability and fine-grained reactivity will be truly something special.

I hope you enjoyed this overview of the islands architecture. If you have any questions or feedback about this topic or any others, please share your thoughts with me on Twitter. I would certainly enjoy hearing from you! And be sure to check out Babbel’s engineering team on Twitter to learn more about what’s going on across the department. Stay hydrated!

Exploring Web Rendering: Isomorphic JavaScript & Hydration

Eric L. Goldstein — Tue, 30 May 2023 18:21:41 +0000

Photo by Martin Abegglen on Flickr

What an exciting time the past few years have been in the evolution of web rendering technologies! Our team at Babbel is hyper-focussed on performance improvements to our applications this year, and we’re going to be using some very cool new concepts and technologies to achieve our goals. As a Principal Engineer, rather than keep my research and knowledge sharing within our walls, I’ve decided to share what I’m thinking about in hopes to expose and teach these topics to a wider audience, grow a dialog with the wider community, and to reinforce my own knowledge - the best way to learn is to teach after all. Before starting, thank you to Ryan Carniato - creator of SolidJS - whose YouTube streams and dev.to articles have been a huge inspiration and source of guidance for my learning and writing about many technologies and frameworks; I strongly encourage you to follow his work. Without further ado, please join me in my 5-part series exploring some of the more interesting modern web rendering techniques; this article is just the start! If you have any questions or feedback of any kind, please reach out to me on Twitter; I’d love to hear from you!

The influx of new performance-focussed frameworks like Astro, SolidJS, and Qwik has indicated we’re entering a new web era, exemplified by them topping the developer satisfaction charts for rendering and front-end frameworks respectively. In addition, considering the growing correlation between performance, search engine rank, and revenue, understanding the progression of web rendering technologies has never been more important.

Rendering framework retention rankings from State of JS 2022

Front-end framework retention rankings from State of JS 2022

The rise in popularity of component-based, single page app frameworks in the early to mid 2010s improved developer experience with the introduction of declarative UIs and simpler APIs. Such simplicity seeking led to rendering being done in the browser, otherwise known as client-side rendering (CSR). While reasoning about an app during development was now simpler than before, application initialization performance usually suffered because now the entire app lived in JavaScript which required it to be downloaded, parsed, then executed thus delaying HTML parsing and asset downloads; beforehand the user won’t see anything at all! An alternative was eventually evangelized known as isomorphic (a.k.a. universal) JavaScript which attempted to combine the best of what the server and browser had to offer.

Ultimately, isomorphic rendering of JavaScript means that a single application can be used on both a server and browser. Specifically, the server renders the application using a technique called server-side rendering (SSR) and the client uses the application to hydrate the HTML page in order to make it interactive; we’ll cover hydration a bit later. Traditionally, server-side rendering involves server-based routing meaning a “full page load”. In other words, when you click a link to navigate to a new page, the server decides what happens when the click occurs including what content is displayed on the next page. Contrast that with client-side routing where those decisions are made in the browser meaning the browser updates the URL, fetches the new URL’s data via API if needed for the route, then updates the UI; consider this a partial page load because usually only the part of the page that needs to change is updated but the rest is unaffected (e.g. the app shell). Isomorphic rendering is effectively a combination of the two: the server renders the full page HTML, then the client mounts the app and takes over all routing duties. In other words, the application starts off as SSR then automatically transforms and remains as CSR throughout the life of the page. See the following images for a visual comparison of the three aforementioned techniques in the same scenario: navigating from a start page (1) to two subsequent pages (2 and 3); note the differences between client-side and isomorphic routing for step 1 after which they operate identically.

Diagram explaining server-side routing; note all interactions cause requests to the server

Diagram explaining client-side routing; note the client does all the work including on initial render (1)

Diagram explaining isomorphic routing; note the server initial render (1) then the client does all the work

Remember that an isomorphic application first involves a server rendering an HTML page using a JavaScript application then a browser hydrating that page using the same application the server used. So what is hydration? Let’s define it: hydration is the process of initializing an application to make a server-rendered HTML page interactive by setting up the necessary application state and event listeners. Traditionally, hydration downloads and executes all components in your application eagerly meaning that doing so occurs as soon as possible, but there are other, potentially more performant options which will be explored in future articles in this series including partial (part 2) and progressive hydration (part 3).

Because the application is shared between server and browser, state is as well. If your app has a single source of state as is often the case with Redux, for example, sharing state between server and browser can be as simple as passing your state object through JSON.stringify() then adding it to a <script> element at the end of your HTML output so as to not be render blocking; more elaborate state models require more complex methods of state sharing.

On the server, the DOM is non-existent so its events can effectively be ignored, but on the client they’re treated normally. Using React as an example, when an application is rendered with React.hydrateRoot(), React is smart enough to know that hydration is client-only so event listeners should be bound. However, when rendering that same application with React.renderToString(), binding event listeners is skipped because that function is part of React’s server-only API. As a result, occasionally your code will need to be environment-aware so client- or server-specific actions can be taken when appropriate. Clearly, while your application may be shared between server and browser, isomorphic rendering has additional mental overhead during development that must be factored in when choosing your desired rendering model.

Isomorphic applications can provide multiple benefits over client-rendered ones. Instead of an empty HTML shell like what’s often used to bootstrap a CSR app, a server renders the entire page’s content into HTML which allows browsers to begin parsing the page HTML sooner. Thus, page assets like images, JS, and CSS begin downloading earlier. Similarly, SEO is improved because web crawlers like googlebot can crawl your pages more quickly with the full page’s content available rather than having to wait for all client API requests to respond and the DOM to incrementally update; the latter can be time-consuming and error-prone for crawlers. Furthermore, because the HTML is fully available and assuming the response per page doesn’t change, you can optionally CDN cache or static build your pages for a performance boost, especially the prior which will cause the response to skip talking to your origin server and be returned from as close to the user as possible; latency and server load is minimized as a result. If your application values quick navigation times, the client-side routing of an isomorphic application after initial page load should act similarly to a CSR app with no server rendering.

For a complete analysis, downsides must be explored as well. Ignoring streaming rendering for now (part 4 in this series will cover it), Time to First Byte (TTFB) for isomorphic rendered HTML is larger than CSR’s static app shell HTML because all server-side API requests need to complete before being included in the returned HTML. In addition, total isomorphic payload size is larger because the aforementioned completed request data is included within the HTML. However, the ability to parse and download assets sooner usually outweighs that downside and results in an overall faster page load. Eager hydration can cause a period of unresponsiveness known as a long task which can negatively affect time to interactive; this symptom is especially painful for devices with slow single-threaded CPUs (I love hardware, too!). In other words, if too much hydration occurs all at once, users will experience freezing of the user interface during page load which is when they are most likely to be interested in interaction; the following articles in this series discuss ways to mitigate this and other problems to improve user experience. Because isomorphic rendering relies on JavaScript for interactivity, user attempts to click a button for example will have no effect until hydration completes; this example ignores progressive enhancement, and mitigation techniques do exist but they often involve loading tiny bits of JavaScript even earlier. Finally, the “double data” problem is an Achilles heel of the design and refers to data needing to be downloaded twice: once embedded into the HTML as content and again in the serialized JSON used to hydrate the application. An example of this repetition is the body of a blog post which gets rendered directly into the HTML and encoded into the JSON used for hydration; if the post content is the vast majority of your page weight, the page has now become effectively twice as large.

Now that isomorphic rendering has been explained, how can it be used? The most easy-to-use options are known as “metaframeworks” which take a base rendering framework like React, Qwik, or SolidJS and add additional features like routing and style management resulting in options like Next.js, QwikCity, and SolidStart, respectively, among others. Try them out and see what works best for you. If you have any questions or feedback about this topic or any others, please share your thoughts with me on Twitter. I would certainly enjoy hearing from you! Happy rendering!