Code Lifecycles

Code has a lifecycle. As software engineers, it should be our goal to shorten these lifecycles. The longer a code's lifecycle, the larger opportunity for bugs and for our code to break. Code is inherently buggy.

Let's talk about a PHP website. A request comes in, we run some php to generate html, send it to the client, and the code is done. It's over. Its lifecycle ends–until the next request starts all over again.

Let's talk about a SPA React website. A request comes in, we send back html and javascript-the javascript renders our page over and over again on the client. Our code's lifecycle doesn't die until the user closes the page. It's effectively infinite.

We should be striving for our code to exist for as short as possible–we should get in, get out, and accomplish whatever we need to do. This doesn't mean it needs to be the fastest–it means we should ensure it isn't possible to do more than it needs to do.

Therefore we should be moving as much of it as we can to a place where it can die: that is, the server. Every line of code that doesn't reach the client is code that has a more defined lifecycle. Less opportunity for things to break, less opportunity for bugs, and frankly, less potential complexity.

1request     response
2  | ---------> |
3        PHP
4
5request     response                          tab closed
6  | ---------> | -------------------------------> |
7                         client side JS
8
9request     response                          tab closed
10  | ---------> | -------------------------------> |
11        RSC           (less) client side JS

There is no dispute that having client-side code unlocks functionality inaccessible to the raw server alone. Even solutions like htmx or phoenix that are server-dominant have ways to encourage writing some client-side code.

But, if we are able to take code whose lifecycle is effectively infinite, and make it defined, we should. That's one reason why I think the ideas behind React Server Components are so powerful, because it allows us to move code whose lifecycle was previously stretched into a place where it is now contained. And we can shorten the code lifecycle even further by moving some of it to only execute at build-time. This code dies after building and can not break because it no longer exists.

When you do need to write client-side code, when you must, you should be able to through simple means: in React that means through composition. That is the power of 'use client'–it lets us escape the server and write code for the client with ease. With traditional SPAs, they are very much an all-or-nothing situation. Either you write all of your code to run on the client, or a hybrid of the client-and-server. But RSCs give us the flexibility to define our code lifecycles by executing components on the server¹¹  or at build-time and letting that code die at its rightful time.