What about React/Vue/Angular?

Summary

In this video, I challenge the industry trend toward single-page applications (SPAs) and argue why server-side rendering (SSR) is often a better choice. While SPAs create smooth experiences, I demonstrate how we can achieve similar results using HTMX without the added complexity. I explain that SSR's unified approach to data handling creates a more manageable codebase, and since most applications primarily perform basic CRUD operations, SSR provides a more straightforward solution without the overhead of maintaining complex API infrastructures.

Transcript

So you might be wondering if you're going to be using React, or Vue, or Svelte to build out the UI, which if you've been following along in the tech industry, it's kind of a fair thought since the whole industry has been moving towards single page applications for the last 10 years, right, which has mainly been driven by the adoption from fang companies and everyone else seemingly just, you know, following along. But for a lot of applications, I think that the quote unquote old school way of building applications is a much better fit. But before we begin, let's start with some basic terminology. What is a server side rendered application and what is a single page application? Those two have acronyms. So the first one is called, also called SSR, and our second one is called SPA. A server side rendered application processes and generates the HTML for each page on the server, sending a fully formed page to the browser. Which is in contrast to how SPA does it, since they send a minimal amount of HTML and rely on JavaScript to construct a page in the browser. SPAs does, in general, create more smooth and an app like experience compared to a server side window navigation. But, as we'll see later on, a lot of this app like behavior we can actually get by using a library called HTMX. And then we also skip a lot of the complexity and overhead that comes with running an SPA. The benefits, in my opinion, that a server side rendering application has over a single page application is a simplified architecture and data flow, as well as a reduced complexity. The first point, a simplified architecture and data flow, is an important one, because it's something that most developers today have not experienced or even been taught. By having the server generate the content, we create a unified process for data handling and presentation, making the client, in this case the browser, more tightly coupled with the server, which leads to a more straightforward and manageable codebase. We do not have to split our codebase into a frontend and a backend, so the entire UI flow essentially becomes one process. So, you might have heard of the term RESTful API, which today for many developers means a JSON based data API. But something has been lost in translation because a JSON based API cannot fulfill the requirements originally stated in Roy Fielding's thesis and Fielding was the man behind the term RESTful. And the idea has been adapted to fit the data needs of today's web application, but it comes with a few hurdles. These data APIs must inherently be generic, since they can be consumed by lots of different clients. So you need to know most of your applications workflow up front, since each one would need their own end point. But at the same time, you must also try to reduce the request overhead. So you don't end up with an N plus one request workflow to get the data that your app needs. And an example of this could be that you call the API to get a resource and then you use that resource to get another resource and another resource and then on they go. One of the reason why the technology GraphQL was invented was to solve this problem. And with all that in mind, you must also maintain and ensure that you do not break the API for all of the consumers. So this means that you have to be very careful when you change a field, you add a field, you update a field. Because you could potentially break a lot of different clients expectations. You're essentially creating a contract that you have to maintain, right? And you do the same thing with the server side rendered application, but you know directly who is consuming it. So, it's much easier not to break a lot of things accidentally. Of course, it's not all sunshine and rainbows with server side rendered applications. Server side rendering can make scalability challenging since you rely more on your servers. But with today's servers, they are very cheap and they're very efficient. So you have to grow a lot before this becomes an argument or becomes a worry. Let's say the argument is true. It is true that you might have an initial longer load time with an SPA because it sends more data. And then afterwards it becomes a lot more efficient since we rely on the client, the browser to do most of the work, right? But for this to really matter, you would have to have so much traffic that you're most likely swimming in money. And you can just hire people to deal with maintaining a data API, right? So it doesn't really become an issue in the same sense when you reach that point. So the last thing is also that user experiences that are highly interactive will not be as smooth in a server-side rendered application, if even possible at all compared to what you get in an SPA for highly interactive applications, which there are very few. SPAs are completely the right choice where you have to pay the cost in terms of complexity and development time. But those applications needed it. However, most applications that you and I interact with, if you don't take something like Netflix or Facebook, other applications from those websites, mainly do four operations, which is create, read, update, and delete. So they're mainly just changing and showcasing data. That sounds simple. You can still build very, very complex applications with those four operations, but the essence of most applications is those four operations. And this is a place where server side rendered applications really, really shine.