The Go Framework Debate: Gin and Fiber vs. Native Routing Evolution

Host: Alex Chan Guest: Marcus Thorne (Principal Engineer & Go Specialist) Host: Hey everyone, welcome back to Allur. I’m your host, Alex Chan, and I am so glad you’re tuning in today. If you’ve been in the Go ecosystem for a while, you know there’s always been this… I don’t want to call it a war, but definitely a very heated "philosophical divide." On one side, you have the "Standard Library Purists"—the folks who say if it’s not in `net/http`, you don’t need it. And on the other side, you have the "Framework Realists" who swear by things like Gin or Fiber to actually get stuff done without losing their minds. Host: To help me navigate this, I’ve got a fantastic guest with us. Marcus Thorne is a Principal Engineer who’s spent the last decade building high-scale microservices, mostly in Go, and he’s seen the good, the bad, and the "dependency-hell" ugly. Marcus, thanks so much for joining us on Allur! Guest: Thanks for having me, Alex! It’s great to be here. And yeah, "dependency-hell" is a very real place, I’ve had the stamps in my passport to prove it. Host: [Laughs] Right? So, Marcus, let’s set the stage. Before we talk about the "new hotness" in Go 1.22, let's talk about why we all flocked to things like Gin and Fiber in the first place. Why did "The Go Way" feel so… slow for a while? Guest: Oh man, it was the friction. I mean, if you wanted to do something as simple as pulling a user ID out of a URL—like `/users/123`—the standard library basically looked at you and shrugged. You had to manually split the path strings, or use regex, or write these massive switch statements just to handle different HTTP methods on the same route. It felt like you were building the car while trying to drive it. Host: Exactly! I remember looking at my first native Go router and thinking, "Wait, I have to write an `if` statement just to check if it’s a POST request?" Guest: Precisely. And that’s where Gin came in and saved the day. It gave us that Radix tree-based router which was super fast, but more importantly, it gave us "Developer Velocity." You could bind JSON to a struct in one line. And then Fiber came along, looking like Express for the Node.js crowd, and suddenly Go felt accessible. It didn't feel like this academic exercise; it felt like a tool you could ship a startup with in a weekend. Host: But there’s a catch, right? We traded that ease for something else. Guest: Yeah, we traded it for "The Black Box." You start pulling in these frameworks and suddenly your binary size jumps, your middleware becomes this tangled web of third-party logic, and you’re locked into their specific way of handling contexts. You’re not really writing "Go" anymore; you’re writing "Gin-Go" or "Fiber-Go." Host: And that brings us to the big shift. Go 1.22 dropped, and the Gophers went wild. Why was the update to `http.ServeMux` such a big deal? Guest: It’s honestly the biggest change to Go web dev in years. They finally added method-based dispatching and path wildcards. So now, instead of that mess we talked about, you just write `mux.HandleFunc("GET /posts/{id}", handlePost)`. That’s it. It’s built-in. You get the ID by calling `r.PathValue("id")`. No third-party code, no extra dependencies. Host: That’s... actually huge. I mean, it sounds simple, but it removes the number one reason people reached for Gin, right? Guest: Totally. It kills the "boilerplate" argument. And from a security perspective, it’s a dream. We’re seeing so much talk about supply chain attacks lately. Every time you `go get` a framework, you’re trusting hundreds of other people’s dependencies. If you stay native, you’re trusting the Go team—who are notoriously obsessed with stability and security. Host: I read an interesting take recently by Stephen Azongo—he was talking about how many of these frameworks have a "2014 mindset." They were built for the problems of a decade ago. Do you think we’re carrying around "legacy debt" by sticking with frameworks in 2024? Guest: I think he’s spot on. Back in 2014, we needed frameworks to bridge the gaps in the language. But Go has evolved. The type system is better, the garbage collector is faster. When you use a heavy framework now, you’re often adding layers of abstraction that actually slow down your cold starts in serverless environments or hog memory in your containers. The "standard library" way is just… leaner. It’s built for how we build apps today. Host: So, okay, let’s get practical. If I’m starting a new project today, am I a "bad developer" if I still reach for Gin? Guest: [Laughs] Not at all! Look, if you’re doing a 48-hour hackathon or you’ve got a team coming straight from Ruby on Rails or Spring, Gin is still a great safety net. It’s "batteries-included." If you need OIDC, CORS, and complex validation and you need it *an hour ago*, use the framework. Host: Right, don’t reinvent the wheel if you’re under the gun. Guest: Exactly. But, if you’re building a microservice that’s going to live for five or ten years, or something that needs to scale to millions of requests with minimal overhead? I’d go native every single time now. The long-term maintenance cost of a framework is real. I’ve spent way too many weekends upgrading framework versions because a breaking change was introduced. The standard library? That code will probably run the same way in 2034. Host: That’s a powerful argument for stability. What about the middle ground? I’ve heard you talk about Chi before. Guest: Oh, I love Chi. It’s the "Goldilocks" of this debate. It’s a 100% `net/http` compatible router. It doesn't give you a custom context or a proprietary "handler" type. It just makes the routing a bit more ergonomic. If you're not ready to go full "pure native" but you want to stay within the Go ecosystem's standards, Chi is the way to go. Host: It feels like the tide is really turning toward this "Standard Library First" mentality. It’s almost like Go has finally grown up and can handle the web on its own terms. Guest: It really has. We’ve moved from "Which framework should I use?" to "Do I actually need a framework at all?" And more often than not, the answer is "Actually, no." It’s a great time to be a Go dev. Host: I love that. "Do I even need this?" is such a healthy question to ask in tech. Marcus, this has been so eye-opening. I think a lot of people are going to be looking at their `go.mod` files a little differently after this. Guest: I hope so! Strip it down, keep it simple. Your future self will thank you. Host: Such a great takeaway. Before we go, where can people find more of your work or follow what you’re up to? Guest: You can find me on GitHub at m-thorne or over on my blog where I talk a lot about Go internals and systems architecture. Host: Awesome. Well, Marcus, thanks again for sharing your expertise with us today on Allur. Guest: My pleasure, Alex. Thanks for having me! Host: And thanks to all of you for listening. The Go 1.22 update is a perfect example of how our tools keep evolving, and sometimes, the best way forward is actually getting back to the basics. If you enjoyed this episode, make sure to subscribe and leave us a review—it really helps us keep bringing these conversations to you. We’ll be back next week with more tech deep dives. Thanks for tuning into Allur! I’m Alex Chan, and I’ll catch you in the next one.