DEV Community: Mike Stelzer

Staying Hydrated with JavaScript

Mike Stelzer — Fri, 21 Apr 2023 17:17:29 +0000

If you are like me, your web journey began when everything was much simpler. Create an HTML page and some CSS, throw it up on an Apache server, and you were well on your way to a website. Flash forward (pun intended) to what you see on the web today: You must choose between a slew of different web libraries and frameworks that all attempt to solve problems in different ways.

In this post, I dive into some of the various methods JavaScript projects are trying to solve for the age-old problem of performance. Specifically, two metrics seem to surface frequently when evaluating web vitals: Time To Load (TTL) and Time To Interactive (TTI).

Time to Load (TTL) is the amount of time it takes for a page or application to load and display its content in the users' browser. This means all HTML, CSS, JavaScript, images, and other assets that are required to render the page have been downloaded. The measurement is usually taken from when the page is requested to when the final asset is downloaded, and the page is completely rendered.
Time to Interactive (TTI) is the time it takes for a web page or application to be "interactive", meaning the user can begin interacting with elements on the page. This is measured from the moment the page is requested to the point in which the page is fully rendered and the JavaScript code has finished executing, allowing for page interactivity.

Background

How a site is rendered--whether at the client or at the server side--directly affects TTL and TTI. For example, with a server rendered page you may see the content sooner but it may take additional time for that page to become interactive.

To better understand why that is, I think it is important to understand the difference between client-rendered and server-rendered applications when it comes to React. When a user makes a request for a page on a client-rendered application, the server returns an HTML document that includes a JavaScript bundle (in the script tags, which also then need to be downloaded), this bundle is then responsible for rendering the UI on the client's machine.

With a server-rendered application, the initial rendering of the UI takes place on the server-side. When a user makes a request for a page, the server generates an HTML document built from React components and returns that document to the user. This page is visible and users can interact with it right away, but until the JavaScript bundle is downloaded, the React components will not be entirely interactive.

Each approach has its pros and cons. While SSR (server-side rendering) can result in better initial load times, SEO benefits, and improved accessibility, it can result in higher server loads and less initial interactivity. CSR (client-side rendering) can result in faster page transitions and interactivity, while sacrificing initial load times, SEO, and accessibility benefits.

Accessibility and rendering techniques

As mentioned above, the rendering technique that is used affects accessibility. Why is that? A few reasons you may see a degraded accessibility experience when using client-side rendering (CSR) include:

Increased initial load times.
CSR relies more heavily on JavaScript for rendering and interactivity. So, a user with JavaScript disabled will be more impacted than a website rendered on the server-side.
Client-side rendered applications often manipulate dynamic elements or interactions with JavaScript on the client-side. Assistive technologies such as screen readers may not be able to properly convey this element or changes. Whereas, many SSR approaches generate HTML with proper markup and accessibility attributes on initial render.
CSR approaches generally update or change content after the initial page load, which may pose challenges for assistive technologies in detecting or announcing updates.

Hydration

In React, and with many other JavaScript frameworks, a process called hydration takes place. What is hydration? Both client-side rendered and server-side rendered applications produce HTML from React components. This HTML may require event listeners or other behaviors such as animations, interactivity, form validation, etc, to truly be interactive. This is where hydration comes in. Hydration is the process of attaching event listeners or other behaviors to the HTML produced by the client or the server. For example, the image below depicts what a typical server rendered lifecycle may look like:

Image courtesy of Next.js Docs

This process can result in slow initial load times when working with large applications. But there are some options depending on your use case to speed this process up. A common approach is to split the JavaScript bundle into smaller, more manageable chunks and load them asynchronously after the initial HTML has rendered. Another approach would be to use SSR to reduce the number of operations the hydration process requires because the initial HTML page already contains the behavior and event listeners.

Partial or Selective Hydration

You may have also come across the term partial hydration. This is when the hydration process only hydrates small parts of the page that require updating. Astro Islands and React 18's selective hydration come to mind in different implementations of this concept. A nice feature with React's selective hydration is that it prioritizes what it is hydrated based on interactions within the page, such as a button click.

While these two implementations are similar in concept, they are different because React's selective hydration is only available within React itself, whereas Astro's partial hydration is part of the Astro framework which accommodates multiple frameworks.

React's selective hydration would be effective when dealing with large, complex components that may require a lot of client-side processing. Astro's partial hydration would be best suited when dealing with small, modular components that can be loaded on an as-needed basis.

Streaming HTML

A new feature in React 18 is the ability to stream HTML. This allows the rendering of a React component to begin on the server and incrementally send the HTML back to the client as it is generated. This will produce a faster initial load and a more responsive user experience because the user can begin interacting with the application as soon as the initial content is downloaded, while still asynchronously loading additional suspended chunks.

A perfect example of this would be an article that has comments below. You can load the critical piece of the page—the article—without waiting for the comments to load. Using suspense, you could instead display a spinner until the comments are ready. The following image shows this scenario:

Image courtesy of Next.js Docs

While React's streaming of HTML may bring a lot of benefits, it's also important to note some potential downsides:

Streaming HTML requires a server that supports HTTP/2 or newer and client-side browsers to support it as well. Older browsers or devices may not support this functionality.
An application using streaming HTML may be more complex than one without and pose a steeper learning curve for a team not familiar with the different techniques being used.
Streaming HTML can improve the initial load time, but it may require careful consideration of caching and performance strategies. These strategies may include managing server-side caching and rendering strategies to prevent server overload due to frequent streaming requests.

Qwik's Resumable Rendering

Qwik is another front-end framework that aims to improve the performance of applications by providing a unique server-side rendering solution. Qwik calls this unique solution resumable rendering.

The first thing to note is that Qwik is not React, nor does it use React. It does use JSX as its template syntax, which means components may look similar to ones created in React. But, you can also use React within Qwik with Qwik React to make transitions easier if you choose to do so.

Qwik avoids the need to hydrate the HTML returned by the server by serializing all the required information as part of the HTML during the SSR process. It also uses a global event handler that relies on event bubbling to intercept all events. This global event handler means Qwik doesn't need to register handlers on individual DOM elements.

Image courtesy of builder.io docs

With hydration, all event handlers are created and attached before the event is triggered (eagerly). Whereas with Qwik, the creation of the event handler happens after the event is triggered on an as-needed basis (lazily). This is done by deserializing the event handler from the HTML which prevents duplication of the work already done by the server.

Qwik is definitely a tool to watch. With it being a relatively newer platform, it may be lacking from a community standpoint or ecosystem of tooling when compared with other frameworks. And because Qwik serializes its handlers as part of its HTML, it requires those to be eligible for serialization which may prove difficult for certain edge cases.

Conclusion

There are many front-end technologies available today, each with a slightly different approach for improving performance and user experience. When choosing which technique or combination of techniques best fits your needs, the answer unfortunately is "it depends". Each and every use case is different, but choosing a familiar technique whose capabilities and limitations you understand is generally a good solution.

How are you building React applications? It's time to move on from Create React App

Mike Stelzer — Tue, 11 Apr 2023 19:07:08 +0000

"How are you building React applications?" This is a question that often comes up with application engineers when they are starting new projects. People tend to gravitate towards what they know, but is that the correct choice? And, with so many options today, how do you know what the right choice is?

While many of us started our React journeys by using the Create React App tool, it's best days are behind it. It's time to evaluate new tools. This blog post covers why it's time to move beyond Create React App and introduces you to new tools, including Next.js and Vite, that can help you build React applications better.

Limitations of Create React App

Create React App was designed with one purpose in mind: To provide an accessible way for anyone with a terminal to create a React application. The open-source tool was ideal for learning or becoming familiar with React.

The benefit to this tool was that developers could begin developing straight away without the need to learn complex build tooling such as webpack or set up a slew of tools such as Babel, ESlint, or TypeScript.

"[Create React App] was intentionally minimal and limited in scope (no configuration, no plugin system) for two reasons. One reason was that, the more feature-rich it is, the harder upgrades will be. The other reason was, I knew that React itself will take a vast majority of our time, and I won't be able to dedicate more than a few weeks sporadically to CRA every now and then."

~ Create React App Co-Creator

Due to this unnecessary need to learn tooling, developers skipped learning the underlying tools their applications were so heavily built upon, causing them to become reliant on this no-configuration style approach. This issue becomes apparent once teams need to break out of the safety net CRA provides.

The CRA developers knew developers would eventually need to enable features beyond the feature set provided, so they created an eject button for teams. The eject feature removed the dependency on react-scripts and copied a snapshot, in-time version of the configuration files used in the project. The snapshot version of these complex configuration files coupled with a lack of individual knowledge about the tooling caused projects to either stop their upgrades or introduce messy updates when needed. CRA even suggests forking react-scripts instead of ejecting for somewhat easier updates, but this also can be a daunting task depending on your use case or familiarity with the tooling.

So, instead of entirely managing these configuration files, teams took to utilizing tools such as Craco to override configurations. These tools also come with their limitations: they were not updated as quickly as CRA, so there was always a lag in implementing new features, and they added an extra layer of complexity to existing tools through overrides and additional tools.

"Realistically, CRA is inherently very limited. It does not follow best practices for performance because it produces client-side only apps. This means it doesn't benefit from optimizations that are commonplace today with other frameworks, such as static generation or server-side rendering. Unless there is a drastic redesign, it won't benefit from future-facing features like Server Components. So if you care about delivering the best user experience, I don't think CRA is the right tool in the first place. It has its use cases, but many other tools now exist that do this job better. CRA still works great for the getting started use case, but you shouldn't see it as the best React app setup. It's not, and isn't meant to be."
~ Create React App Co-Creator

Still not convinced to move on from Create React App? Even the React Docs no longer recommend Create React App for bootstrapping a new project.

Next.js as an alternative to Create React App

Next.js, much like Create React App, is a no/low configuration framework to quickly get a project up and running with React. Next.js does offer a greater feature set and the ability to natively override build tool configurations based on your needs.

Benefits of Next.js

React natively renders content in the browser through client-side rendering. This means the end user downloads all the assets and code necessary for the browser itself to convert the React code to a native DOM output for the browser to display. Next.js, on the other hand, allows the use of both client-side rendering as well as server-side rendering, which means the server interprets the code and produces the DOM elements required for the browser to display.

By using server-side rendering (SSR), the server is able to optimize the delivery of JavaScript, CSS, and other asset chunks in preparation for the browser to display results in a faster initial load time. I won't spend time diving into the nuances of this as many other individuals have already done so. If you are interested, check out this article showcasing the comparison of CRA vs Next.js performance differences.

In additional to SSR, Next.js provides additional options for data fetching, providing alternative options for rendering based on the application's use case.

Next.js provides native TypeScript support requiring a zero-configuration approach to using TypeScript in your projects. Next.js also includes a built in router without the need to include additional libraries such as React Router. All-in-all, there is a long list of features provided by Next.js such as:

image and font optimization
built-in CSS support
build caching
linter setup
page and layout support

Be sure to check out the Next.js documentation page to read more.

Now, you may be thinking to yourself: "Next.js doesn't seem to solve the problem of the development team not learning the toolchain the application is built on." And, you are correct.

Even though Next.js provides additional configuration options and the ability to override most of the tooling it uses, it still masks the complexity of the underlying toolchain. In many cases, this is acceptable because you can access tools to modify, if necessary, while not recreating the wheel every time you want to do something relatively basic.

Downsides of Next.js

Next.js has a relatively poor plugin ecosystem
Customizing routing can be cumbersome
Extremely opinionated (could also be a benefit)

Roll your own with Vite

What about rolling your own? Most people that have only ever used CRA, Next.js, or similar tools will think that seems like a lot of work. In the past, it usually did require quite a bit of knowledge about webpack, so you aren't wrong. But tooling has come a long way, and tools like Parcel, NX, and Razzle have simplified the process. Even more recently, Vite has gained an ever-increasing market share.

"Why?" you might ask. Vite is built on top of esbuild, a Go-based bundler for the web that is 10-100x faster than other bundlers such as webpack. Vite is also platform-agnostic, so you can learn the tool and use it for many applications.

Vite has a great plugin ecosystem because it leverages the same plugin interface as Rollup, meaning most Rollup plugins are also compatible with Vite. The Vite guide offers more reasons for why you might want to check out Vite.

It also has a nice tool create-vite which aids in the creation of a a project using a set of predefined templates much like CRA does. As of this writing, currently supported templates are:

vanilla
vanilla-ts
vue
vue-ts
react
react-ts
react-swc
react-swc-ts
preact
preact-ts
lit
lit-ts
svelte
svelte-ts

Vite isn't quite rolling your own, but is getting much closer to the toolchain than the previous options.

Other alternatives?

Obviously, there are tons of other options available besides the ones listed above, but I wanted to showcase a natural progression developers can take within the React ecosystem. Below are some links to additional popular options other developers use for building and bundling their React applications:

Parcel: Prides themselves on the zero-configuration approach.
Nx: Most notably known as a monorepo tool set with a vast plugin ecosystem.
Razzle: I've never used it personally, but based on what I can tell it seems to be an attempt to enhance the Create React App concept, enabling CSR/SSR while also working well with libraries other than React.
Gatsby: Excels in static site generation and uses GraphQL for data management.

What's next?

It is great to see so many options available for both new and old developers. It seems as though every few months, another player emerges in the space looking to challenge and disrupt the React ecosystem. Because of this ever-changing landscape, it's best not to over-invest time and resources on one tool, but instead lean on the experts in the communities such as Next, Parcel etc. for a somewhat-opinionated approach to solving similar problems.

Looking forward, some other projects that I find have some really great potential in the approach they take to simplify the toolbox are Remix and Astro.

Remix: is a web framework built with web standards and progressive enhancement in mind. Check out their project page for more information.
Astro: is a web framework that encourages the use of the island architecture and more checkout their project page for more information.

References

Issue response from Meta Co-Creator of Create React App