Made withSvelteClip

Why We Switched From Svelte Kit To Golang + HTMX

A

Anthony GG

Creator on the Svelte channel

Watch on YouTube ↗

85K viewsDec 8, 20239:54 runtime

Discover why a funded startup transitioned from a modern SvelteKit and Golang stack to a simplified architecture using only Go, HTMX, and the Templ templating language. Learn about the practical downsides of maintaining a separate SSR frontend, including redundant request…

Chapters

#svelte#clip#frontend

The Problem: Frontend/Backend Friction

When building V2 of their platform, Lychee initially chose a SvelteKit frontend with a Golang backend. This created several architectural problems:

Request Proxying: The SvelteKit server-side rendering (SSR) layer ended up just proxying API calls to the separate Go backend, adding an unnecessary network hop and layer of complexity.
Type Duplication: They had to maintain and synchronize types (e.g., TypeScript) between the frontend and backend, leading to redundant work and potential for errors.
Developer Friction: A developer working on a full feature had to navigate two separate codebases, manage state between them, and handle duplicate logic for things like authentication.

Note
The core issue was that the frontend's main job was simply rendering HTML from data provided by the backend, but the separation introduced significant overhead without providing enough value, especially since they didn't have a mobile app that would consume the API independently.

The Solution: A Type-Safe Go Monolith

The team decided to eliminate the separate frontend dependency entirely and render HTML directly from Go. The main blocker for this approach was the lack of type safety in Go's native html/template package.

Tip
The Game Changer: Templ A colleague discovered Templ, a templating language for Go that solves this problem. Templ allows you to write type-safe, component-based HTML templates directly in your Go project.

Key features of Templ that enabled this architectural shift:

Type Safety: Templ files are compiled into Go code, so the data passed to your templates is checked by the Go compiler. No more bugs from typos in map keys.
Go in HTML: You can write standard Go logic (if-statements, for-loops) directly within your template files.
Component Model: It encourages building reusable components (e.g., inputs, layouts), similar to React or Svelte, but on the server.

The New Stack: Go + Templ + HTMX

The simplified, consolidated stack is composed of:

Golang (with Echo): Handles all business logic, routing, and now, HTML rendering.
Templ: Used as the view layer to generate type-safe HTML.
HTMX: Added for client-side interactivity and partial page updates without writing complex JavaScript.
TypeScript/JavaScript: Used sparingly for specific use cases that require complex client-side interactions not covered by HTMX.

Core Benefits

This shift resulted in significant improvements:

Increased Developer Velocity: No more juggling between frontend and backend codebases.
Simplified Deployment: Deployment is now a single binary. A git push triggers a build and deploys the entire application in one go.
Reduced Complexity: Eliminating the frontend proxy layer and type duplication makes the entire system easier to reason about and maintain.
End-to-End Type Safety: From the database to the HTML, the entire request-response cycle is type-safe.

Ditching Frontend Frameworks

We finally did it. We completely get rid of our frontend dependency: Next.js and SvelteKit. And we are only using Go with HTMX. And this is not a meme, this is not a clickbait. If you want to know why we did it and how we did it, you definitely need to watch this video.

But first of all, if you're not yet subscribed to my Channel, please consider subscribing. Give me a thumbs up and leave all your questions in the comments. And of course, jump into the Discord community. All links in the description.

The Project: Lychee's V2 Rewrite

Right. So first of all, um, who is this? It's Lychee, right? So basically Lychee is a company I, uh, started, founded two years ago with a, with a couple of other good people. And, um, we recently actually got a Series A, uh, funding of 8 million. So it's not, it's not a joking company, right? It's, it's a big deal. We also acquired two other companies.

And two years ago, we, uh, wrote our platform or marketplace in, uh, Next.js, right? Everything in Next.js, everything was fine, uh, no big of a deal, good piece of technology, right? But of course, right now we, we need to scale a lot. Uh, we need to rethink how our marketplace is working and we decided to make a V2, right? A complete rewrite. Sometimes, hey, it is what it is. So with all the feedback we gathered over the past two years, we are going to make a version two.

And, um, we were thinking, okay, cool, we have the opportunity to rewrite. What are we going to use? And we decided with three other people, which basically me included, so two other people, we decided to go with SvelteKit in the frontend and Go in the backend. Sounds like a power deal, you know what I mean? Sounds like a good stack to, to, to work in. And that's true.

The Problem with a Separate Frontend

But, but we came into some, some, some problems. So this is the why part, right? So we have SvelteKit in the front end, Go in the back end. Um, but, but the only thing we were doing actually was we didn't want to use client-side rendering on the front end, right? So we were using SvelteKit with the server-side rendering, but we had all our business logic sitting in the Go backend. So the only thing we were doing was just rendering HTML, duplicating the types—TypeScript—and proxying the request to the backend, right? That's the only thing we're doing. So there's a lot of shenanigans going on.

Nothing, right? So if we have a handler, uh, if we have some, some kind of an API call, uh, in, in, in the backend that returns some JSON, we needed to go into the front end, render the HTML, make the types, do the call, but actually just proxy it, right? It's on the, it's on the backend, right? So it's not from the, it's on the server-side, uh, stuff from, on SvelteKit, instead of the client-side stuff. So it's basically just a proxy, right? Yeah. And that was just annoying because if I was working on the backend and I needed to just change some little, some small little HTML value or whatever in the front end, I just needed to open up the whole SvelteKit stuff. I needed to make the types, I needed to make the proxy request, I needed to do all, do all that authentication needs to be okay, the user yada yada, the state... it was annoying.

So we did the thinking process like, guys, listen, do we really need to have that front end complexity? Right? Although our marketplace is very interactive, right? It's a big thing, it's a lot of things are happening, but still, is it worth it to have these two separate things, the front end and the back end, especially if you don't have a mobile app? Right?

If you have a mobile app, you could basically question what we're doing, but we don't have a mobile app because using Lychee on a mobile app is basically just, I don't know, playing soccer with no legs, you know what I mean? Uh, you don't do that. Maybe we will later on, but it's going to be a subset, right?

The Game Changer: Templ for Go

So, we were thinking, guys, listen, we need to get rid of this, of this, uh, of this front end dependency. But the only thing that was holding me back, because I did a lot of Go backends like PHP, like Laravel, or like Ruby on Rails, where you have everything in your backend and you render templates, which is just a breath of fresh air to work in. The problem with Go is that your templates are basically not type-safe. That's the only problem you have in Go, right? Because you have a map with some data, you want to basically use it in your HTML, but if you, it's a map, so it's not, it's not type-safe, right? If you mistype a string, you have no value, and then debugging is going to be very hard, especially if you have a lot of stuff going on, a lot of templates.

But Joel from, uh, also from the community but also, uh, an employee of Lychee, he came up with this. He came up with this. He said, Anthony, listen, look at that. Templ. And I said, what the hell is that? An HTML templating language for Go that has great developer tooling. And boy, oh boy, it's completely insane. People are sleeping on this. I don't know what, I never heard of this. This is just a sleeper thing, especially if you know how to use it, right?

So it's just basically template files, but you use them as if it's just a Go file. So it means that you can write Go in your HTML, a little bit the same as using a function in Next, in React actually, where you're returning a JSX. It's actually almost the same, right? So this completely changes the game because now you have type-safe values, right? It's just Go, it's just Go, it's crazy. For example here, right? You have this index with errors, you can have layouts, you can just write... where there's a good example? You can just look at that. This is a div and you can write Go inside of this thing. You can make, you can even make input components. You can make... it's crazy. Let me know if you want to see an in-depth video on how we set that up. If you want to see an in-depth video on how to use that, right, on how it works, on how we made it work. Like, it's crazy, right? Let that know in the comments if you want to see that. If you have enough comments, if you have enough likes on the video, I will make a special tutorial for this because I think it's, it's a sleeper stack. And if you basically use it well, man, this is, this is insane what's going on here.

Yeah, so, um, yeah, you can see you can just write Go. And in your handler, let me open up a handler here, is our handler. You can see what you do here is basically, um, for example, if you have errors here, if you have templates, if you have sign up errors, we can just return login.Index with errors, which is basically just, uh, this thing, right, with errors directly from Go, right? So you have typed errors and you can do whatever, whatever you want with that, right?

Um, yeah, it's, it's just, it's that easy, right? The cool stuff is with this templating thing is that it works very good in VS Code because there is a plugin, I think it's also for Vim, not quite sure, you need to check it, which you can go to definition and all these stuff, right? Isn't that amazing? You can basically just do boom, you're... it's, it's insane. It's crazy. Uh, you can see what Joel is doing here, a shared logo. So it's a complete component stuff. It's wild, guys, I swear, I cannot even stop talking about it. It's just insane. So big grads to Joel for finding this because I didn't know, right? So that's, that's what, that's what it is, right?

New Stack in Action: Go, Templ & HTMX

And if you want to build that, I don't know if it's going to run, but you just make run. It's compiling these templates like a madman, right? It's compiling all these templates. It's generating Go code for you and you don't need to look at it. And it's just boom. Using the Echo framework, by the way. Um, if you want to know why, if you want to know why, let me know, I will make a video about it, right?

So that's actually it what I want to show you. We're also using HTMX here and there, um, for minor stuff. Uh, I'm not quite sure where, but it's just very minor, right? So if you want to have some, we have some a couple of use cases, but we didn't port everything yet. But I'm going to definitely make a follow-up video where we're using HTMX where needed, right, to, um, reduce the amount of TypeScript/JavaScript we need in the front end.

Although what I want to show you is that we use some stuff right, because there are some use cases where you really need that JavaScript. Well, that's no problem. You just do that, right? Of course, I did not do an npm run or npm build or something. Um, that's why this is basically, uh, still barking, but you can write just JavaScript, TypeScript here and, uh, use that with these templates and all that stuff. Insane. I know. It's, it's amazing, guys. Uh, this speeds up our, our, uh, development process, uh, done right. Because now we don't need to juggle between front and back end. Uh, deployment is just a breeze, man. With the Git-go runners on our server, we just boom, we push to master and it's deployed, right? It's just a make run and, and it's there. That's the power of Go, right?

Conclusion and Next Steps

Um, yes. So that's it, guys. Let me know, check out, I will put some, some, uh, links in the description. Check out this templating language, pretty amazing. Um, like this video, leave some comments, especially if you want to see me make a follow-up video, uh, with a tutorial on how to set that up. Leave it in the comments. Give me a thumbs up. Boost this video into the algorithm, and I'm looking forward to see you in my next video or live stream. Peace out.