Overview of Web Application Approaches
The video compares different approaches to building modern web applications, focusing on Single-Page Applications (SPAs), traditional server-side rendering, and modern hypermedia tools. The goal is to balance interactivity with simplicity and reduced complexity.
Single-Page Application (SPA) Model
SPAs use frameworks like React or Angular to separate frontend and backend into two distinct applications. The frontend manages routing, state, and rendering, while the backend exposes APIs. Although powerful, this approach introduces significant complexity, tooling overhead, and large JavaScript bundles.
Traditional Server-Side Rendering
The classic server-driven model relies on full page reloads and server-rendered HTML. While simpler in architecture, it can feel less interactive and requires custom JavaScript for dynamic behavior and smoother user experiences.
HTMX and Modern Hypermedia
HTMX extends HTML with attributes that allow elements to trigger HTTP requests and update parts of a page without full reloads. It enables partial page updates, proper HTTP methods, server-driven UI state, and minimal JavaScript, preserving simplicity while improving interactivity.
Datastar Enhancements
Datastar builds on HTMX concepts by adding reactive bindings and modern tooling support. It integrates server-driven updates with client-side reactivity, enabling dynamic interfaces without large JavaScript frameworks, while keeping the server as the primary source of truth.
Benefits of the Hypermedia Approach
This model emphasizes simplicity, performance, and centralized application logic on the server. It reduces client-side complexity, improves SEO, supports progressive enhancement, enhances security, and simplifies testing and maintenance.
Next Steps and Practical Application
The upcoming episodes will demonstrate applying Datastar to a blog application. The aim is to showcase how modern, interactive applications can be built with minimal complexity using server-driven techniques.
So now that we have an understanding of what hypermedia is and why it matters, I want to go through what options are there and also how do I actually build modern web apps using the hypermedia approach in a world where users expect these switch interactive experiences and not these 90 style form submission kind of application.
So in this episode, we will cover the SPA approach, the traditional server-side approach that we've been using so far. And then we will be going over two of at least my favorite libraries for doing modern hypermedia, which is HTMX and Datastar. Let's touch upon the single-page application approach with frameworks like React, View, Sweld, Angular, that has become the default way to build
build the user phase applications in the last few years. So with this model, you're essentially building two applications, right? You have a backend that exposes typically a JSON API, where you also handle authentication and business logic, data persistence or interacting with the database, right? So everything that we are doing, you're doing there. And then you have another application that is the front end, which is
purely built in JavaScript that runs in the browser that manage its own routing and also manage its own state and UI rendering. The typical architecture will look for, if you take our stack, it will be a Go server that has REST or GraphQL endpoints. It can also be other protocols, but it's typically REST and GraphQL. You will then have React app that makes fetch calls to these endpoints.
You didn't need to manage the state client side for something like redox or sustain. And then you also have to handle the routing. You probably would like to have TypeScript for some type safety. You need a built system. If you also want to have SEO, you probably need to use a framework like NextJS or Svelkits or what's it called, ViewKits? I can't remember.
This is starting to build up just to get to the basics, right? And then you still have something like calls. You have JSON web token, so session management across different origins. You have these optimistic updates. You need to optimize the bundle size. You have code splitting, you have error boundaries. You need loading states. So we are typically starting to get used to these skeleton UIs where everything is just flashing at us until the data actually loads.
And you can build incredible user experiences using these tools. But it adds a real measurable amount of complexity or complexity cost to this application. And for most applications, you don't need all of this. You are not building rich user experiences, even if you might think so. You don't need it. Most applications simply need to display data
in an intuitive and nice way and make it easy to work and solve a problem. You don't need a space for this. All the infinity scroll, all the search, all of the, you click one element and some other element update, right? You don't need a space for this. So let's
before we jump into the modern hypermedia tool to just quickly touch upon the traditional server side that we have been using so far. So we have a proper image of the landscape. The traditional server side approach is what the web was built to do. You have a full page refresh that can have a jarring feel to it now that we are getting used to these apps on our phones where we don't have these flashes
whenever we navigate pages or we update something. We also have issues with maintaining, let's say, like a scroll position can be tricky. File uploads can reset navigation. Real-time updates to the UI when you upload a file or you do some operation that calculates something. That can also be quite tricky. And these complex interactions still need a lot of custom JavaScript.
And this was one of the things that the SBA approach tried to solve to get this app-like feel that we have on the phone into the browser and make it easier to do that. And it definitely, definitely did compared to a traditional server-side approach. So traditional server-side approach is where we come from. And then we, for the past 10 years or so, at least at the time of recording, we have been going towards the SBA. But now let's look at modern hypermedia
and especially look at HTMLX to see how that library extends the capabilities of HTML to build what you would expect from a modern application, but using, let's say, the traditional server-side approach tools. HTMLX simply extends HTML's hyper-media capabilities by letting any element trigger an HTTP request and update any part of the page.
This means we can add hx, they're called attributes to our HTML elements and then do operations on elements. So we can add a hx get to a button that can then fetch some data from the server and then it can target a specific element on the page. So we don't just refresh the entire page, we only update something based on the response that the server sent back.
We are also now free to use, let's say, quote unquote, the correct method. So we can also use puts. We can use deletes so that we don't need to always do post request or get request from a formal element. We can actually do a delete request. And we don't even need a formal element and when more on certain features where we can just
have like a button that sends a delete request. For example, if you want to delete an article, you can just live on that button. We don't need a form. We just need to send a request to an endpoint that will delete that article and send back a response. So we get Ajax request without JavaScript. We get partial page updates. We can utilize CSS transitions. We have web support through their extensions. We have also servers and events through their extension.
The history is, the browser history is supported. And this really makes it so that your server is driving the application, is driving the application state. That is where you decide what gets updated in the UI and not having to merge what is happening in the back end with the front end and make sure that those two states are in agreement of what is happening. Now, this idea is really
powerful and you can build some really powerful application using this tool. But to do some frontend interactivity, you will need another tool. You will need, you will need something like, I'm completely forgetting what's called Alpine JS, for example, that you can do to do interactivity in the front end without having to write a lot of custom JavaScript. Now, the next tool we're going to be looking at is something called Datastar and this
It's a more modern approach to this idea that XTMX really brought onto the field, into the tech space and adds reactive bindings into the library so we don't need to add in this extra library to do some funding and activity. So DataStar took this idea from XTMX
and wanted to expand upon it. I think traditionally the author of Datastar wanted to have TypeScript support with the author of HTML. I can't exactly remember, but it was something along those lines and then the author of Datastar started to build his own library. And he, instead of trying to extend what is already there, so one of the key goals of HTML is to get HTML into the HTML specification so you don't need HTML.
whereas DataStar tries to build on top of these ideas with modern tooling. So for example, it's using fetch, which makes it so that we can interact with servers and events instead of pure regular HTML responses. It also adds reactive bindings similar to what you would get from Alpine.js, right? But it's specifically designed for server-driven applications, so we can start to
to both have reactive reactivity in a UI without the server. But the server can also target these reactive UI elements if we want to. So the server is still in charge. It's still deriving what the state is on the front end. So DataStar gives us reactive bindings, servers and event updates. And this can be one time or it can be an open connection. So you can easily send a lot of events.
You can think of this kind of how ChatGPT or Claude do the response whenever you chat with it. So the way that they send down the chat responses is through server-set events. And this is the same approach that Datastar uses. We can take that with declarative event handling, smooth transition, and minimal JavaScript footprint, and build really modern and beautiful applications that work really, really well together.
Let's just quickly round up here. So why are we doing this approach? Well, the main point here is simplicity and performance. We have the application logic live in one place, which is in the back end, which even if you go to SPA, a single page application route, you still have that logic there, right? We are just making it the only place that determine the state of the application. We don't have any state circumcision or API versioning. We don't have any client-side routing complexity.
We ship a tiny amount of JavaScript, like HTML is 14 kilobytes and data size even smaller than this, which when you compare to a typical React bundle, it's nothing. You typically see React applications ship down megabytes instead of kilobytes. We also have SEO-friendly pages
from the beginning, so we are server-side rendering the HTML, which is what search engines use or can understand. They can't really understand single-page applications. You need logic on top of that to be able to have server-side rendered HTML with single-page applications.
We have progressive enhancement. Progressive enhancement. Our app will work without JavaScript. We can still submit. We can still navigate. We have faster development time. You have less code to write. You don't need to try and version an API and make sure that you didn't break something because you updated an API endpoint because these are, in nature, generalizable.
should be able to use that endpoint. That means that you have a lot of different pages of services that can utilize these endpoints and you need to make sure that you don't break them when you make a change. We don't really have that issue here because the logic is tied together much more tightly. We have better security. The logic is on the server. You have one place to enforce authorization and validation. There's no sensitive business logic in the browser.
It's also easier to test. We don't need complex testing setups to test our applications. So in the next few episodes, we will be applying Datastar to our blog to add some interactivity and also show you, give you some examples of what you can actually build with these tools and hopefully illustrate how simple this is to work with.
