Module 1 - Introduction
1. Welcome to the course2. Why Go3. Why start and build a blog?4. What about React/Vue/Angular?5. Getting setup and source filesModule 2 - Tech Stack Walkthrough
1. Introduction to Golang Part 12. Introduction to Golang Part 23. Introduction to Golang Part 34. Structuring Golang Applications5. Templating with Templ6. Just enough interactivity with HTMX7. Getting started with postgres8. Servers, routers and endpointsModule 3 - Creating the MVP
1. What are the minimal requirements?2. Creating our first views3. Basic Echo setup4. Creating our Base Templates5. Tailwind & Utility-first CSS6. Embedding Assets7. Styling the Landing Page8. Styling the Article PageModule 4 - Managing Content
1. Choose your own adventure2. Writing in Markdown3. Parsing Markdown to HTML4. Frontmatter and Meta Information5. Serving the Content6. Making our Code examples look niceModule 5 - Adding the Database
1. What is a Migration?2. Our first Migration: Posts Table3. Creating the Database Layer4. Showing the Latest Posts5. Slugs and Human Readable URLsModule 6 - Managing the Blog
1. What are the minimum requirements?2. A new layout approaches3. Creating a rough outline4. Our second migration: Users Table5. Introduction to authentication6. Storing passwords securely7. Authenticating users8. Remember me9. Managing posts using a hypermedia API10. Our third migration: Altering Posts Table11. Only show posts marked readyModule 7 - Adding Subscribers
1. What are the minimum requirements?2. Our fourth migration: Subscribers Table3. Creating the subscription form4. Adding some interactivity with HTMX5. Saving new subscribers in the database6. Verifying subscriber emails7. Our fifth migration: Tokens Table8. Email validation view9. Email validation tokens10. Sending validation emails with SES11. Making it all come togetherIntroduction
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.