Reactive JavaScript: The evolution of front-end architecture

One of the most dynamic areas in software development today is front-end architecture. Several innovators are pushing the state of the art to devise more powerful ways to build dynamic user interfaces. Much of this work is happening at a furious pace and right out in the open.

Thanks to a number of open source JavaScript projects, such as SvelteKit, Solid, React, Qwik, and Astro, we have a front row seat to the evolution of the future of the web. Here’s a guide to understanding the action.

Also on InfoWorld: 7 tools transforming JavaScript development ]

What is hydration?

Much of the activity around improving modern front-end architecture is focused on what’s called hydration. To understand what hydration is and why it’s central to modern front-end architecture, let’s get a grip on the high-level concepts at play. To deliver the wonder of reactivity, every framework must handle the three aspects illustrated in the diagram below.

javascript reactivityIDG

The high level aspects of reactivity.

The basic message in the diagram is that the framework is responsible for framing the view, holding the state, and managing the interaction between them. (If you are familiar with the MVC pattern, you’ll hear that echoed here.)

Once these three pieces are in place, you’re good to go. The user can see the page and interact with it. 

The naive, or default, approach is to simply take everything the client needs—the frame, the reactive code, and the state—and send it over. The client (the browser) then does the work of displaying the frame (aka, painting the UI), interpreting the JavaScript, and tying in the state.


This approach has the wonderful benefit of simplicity, both for the code at work and for the human minds trying to understand it. It also has a big downside: The initial page render has to wait on everything, and the user has to sit through all of that network and browser churn. Also, unless care is taken, the page will tend to display and then embarrassingly rearrange itself into the final layout. Not a good look.

[ REGISTER NOW for CIO’s Future of Work Summit – FREE TO ATTEND on June 14-15 ]

This inspired developers to try rendering the initial page on the server first (server-side rendering or SSR) and send it over. Then, the user has a decent page to look at while the rest of the code and state is sent and bootstrapped. This is a great simplification but that’s the basic idea.

The time it takes to get the basic layout in place is called first contentful paint (FCP).   The next milestone the page needs to reach is measured by time to interactive (TTI), meaning the time until the user is able to actually use the page. 

Read more about the blog in-depth here.