Cloud Hosting

As you may have noticed, the Start a New React Project section of the React docs no longer recommends using CRA (Create React App). Create React App used to be the go-to approach for building React applications; (that only required client-side routing and page rendering). Now, however, the React docs suggest picking one of the popular React-powered frameworks that support server-side rendering (SSR).

Ive built applications with everything youll see on that list of production-grade React frameworks, but I also spent many years building SPAs (Single Page Applications) that only needed client-side functionality and everything was fine.

Whilst there are many applications that do need server-side rendering, there are also many applications that dont. By opting to choose an SSR React framework, you might be creating problems rather than solving them.

As the acronym suggests, an SPA only has a single page. An SPA might have navigation, but when you click from page to page what youre experiencing are routes, not pages. When you navigate to a new route, React takes over and hydrates the page with HTML and (usually) data that has been sourced using a client-side HTTP request.

SSR applications are different. Server-side rendered applications actually do have pages. The data is sourced on the server, where the page is compiled, and then the final output is sent to the browser as a complete HTML webpage.

As noted, with SSR you need a server and usually this will involve a cloud provider. If your SSR framework only really works with one cloud provider, you might end up experiencing vendor lock-in. Thankfully frameworks like Remix and Astro are server agnostic, so you can either bring your own server, or use an adapter to enable SSR in your cloud provider of choice.

One problem that crops up again and again is spinner-geddon; where each time you navigate to a new page, youre presented with a spinner animation to indicate that data is being requested, and only after a successful HTTP request completes will the page become hydrated with content.

An SPA isnt great for SEO (Search Engine Optimization) either, because as far as Google is concerned, the page is blank. When Google crawls a webpage, it doesnt wait for HTTP requests to complete, it just looks at the content/HTML in the page, and if theres no HTML then how can Google rank the page?

Because of this (and a number of other reasons), there has been a shift in React application development towards server-side rendering. But, whilst both of the above sound like considerable problems are they, really?

The classic developer response will likely be: It depends. And it really does! Ill now tell you a short story about an SPA I built a few years ago, so you can judge for yourselves.

Rewind the clock to 2018, Id been hired by a tech consultancy company that had been brought in to perform a digital transformation for a large financial institution based in London.

My first project was to build a browser-based solution that would replace an antiquated piece of licensed software that was no longer fulfilling its duties, not to mention costing the company money. The application was for internal use only and would only ever have three users: Margaret, Celia and Evelyn, a delightful team of people who were nearing retirement age, but who played an important role in the firm.

The application I built took approximately eight weeks to complete, only used client-side HTTP requests to fetch data from an API, had authentication, was deployed using an existing Azure DevOps pipeline, and wasnt Search Engine Optimized.

Margaret, Celia and Evelyn absolutely loved it, and they didnt mind the occasional spinner since the app solved a problem for them. It also solved a problem for the firm: no more expensive software licensing. I have it on good authority that its still in use today. I also happen to know that Margaret, Celia and Evelyn have all since retired, in case you were wondering.

I think they are. There are many internal applications that will never see the outside world and wont need to use any of the features that come with the more modern React-powered SSR frameworks. But since the React docs are no longer recommending CRA, what else could you use if you were building an SPA today?

Vite can be used alongside React and steps in as a more modern replacement to Webpack (the module bundler used by CRA).

Vite is a build tool that aims to provide a faster and leaner development experience for modern web projects.

I thought about turning this into a tutorial, but theres really no point.

The Vite docs cover everything youll need to know in the Scaffolding Your First Vite Project section; and choosing from the CLI prompts, youll have a React app up and running in about ~20 seconds.

Youll also see from the image above, Vite isnt only a great choice for building React applications, its also suitable for use with other frameworks.

In short, bundling.

When developing an application, code is split up into smaller modules. This makes features easier to develop and allows common code to be shared among different parts of the application. But, at some point, all those modules need to be bundled together to form one giant JavaScript file. This giant JavaScript file is required by the browser to run the application.

Bundling occurs whenever a file is saved (which happens hundreds of thousands of times during the course of development). With tools like Webpack, bundles have to be torn down and rebuilt to reflect the changes. Only after this bundling step is complete will the browser refresh, which in turn allows developers to actually see their changes.

As an application grows, and more and more JavaScript is added, the bundler has more and more work to do. Over time, this bundling step starts to take longer and can really affect developer productivity. Vite addresses this by leveraging native ES Modules and HMR (Hot Module Replacement).

With Vite, when a file is saved, only the module that changed is updated in the bundle. This results in a much faster bundling step and a much more productive and pleasant development experience.

There are a number of other benefits to using Vite, which have been clearly explained in the docs: Why Vite.

So there you have it, out with the old and in with the newbut, the legacy of the React SPA can live on!

Naturally, there are many cases where an SPA isnt the most suitable choice. However, when it comes to SPA or SSR, its not either-or its both-and.

Follow this link:
SPAs and React: You Don't Always Need Server-Side Rendering - The New Stack