Back to Golang: Why I Switched From Static to Dynamic Again
Not long ago, I wrote a post explaining why I abandoned my dynamic Golang website for a static architecture on Netlify. I argued that static files were the future, that AI could maintain them effortlessly, and that simplicity was the ultimate goal. You can read that post here.
I was wrong. Well, not entirely wrong — the reasoning was sound at the time. But the landscape shifted, and so did my needs. I switched back.
Here is why.
Static Sites Gave Me No Control
The promise of static is simplicity. The reality of static is limits.
With a static site, you get HTML. That's it. No database queries, no dynamic content, no server-side logic. Want to show related posts based on tags? Generate a search index at build time. Want a CMS? Bolt on a third-party service. Want user authentication? Add another service. Every dynamic feature becomes an integration problem, a workaround, or a compromise.
I missed having a real backend. I missed writing a SQL query and getting results immediately. I missed the ability to build features in the language rather than stitching together APIs and build scripts.
Static sites are great for brochures. They are painful for anything that resembles an application.
AI Got Better — Much Better
The original argument for static was that AI could maintain it. LLMs struggled with complex Golang codebases, so I simplified the architecture to meet the AI where it was.
That was months ago. AI has moved fast.
Models like Kimi 3 and GLM 5.2 can handle large, complex codebases with ease. Context windows have grown. Reasoning has improved. The barrier that drove me to static — AI's inability to work with dynamic code — has largely disappeared.
The irony is that the thing I simplified my architecture for got good enough to handle the architecture I simplified away.
Full Control
With a dynamic Golang site, I control everything. The routing, the database, the templates, the middleware, the caching, the deployment. If I want to add a feature, I write Go code. If I want to change behaviour, I change a controller. No external services, no API limits, no vendor lock-in.
Static sites force you to depend on platforms. Dynamic sites give you ownership. I wanted ownership back.
Easy Deployment Changed the Game
One of the original arguments for static was deployment simplicity: push to Git, Netlify handles the rest. That was a real advantage — at the time.
Today, self-hosting has caught up. Tools like Dokploy and Coolify make deploying a Docker container as easy as pushing to Git. Automatic SSL via Let's Encrypt. One-click databases. Git-based deployments. The gap between "push to Netlify" and "push to your own server" has shrunk to almost nothing.
And for databases, Turso has been a revelation. A distributed SQLite-based database that lives at the edge, scales globally, and has a generous free tier. It gives me the simplicity of SQLite with the reach of a managed service — perfect for a dynamic Go app that needs a database without the ops overhead.
And when you self-host, you keep the keys. No platform risk, no pricing changes, no feature deprecations.
My Framework, My Rules
I built a custom CMS in Go. It has a block editor, a blog system, a media library, user management, and an admin panel. It does exactly what I need, nothing more, nothing less.
With a static site, I was constantly working around the limitations of the format. With my own framework, I work with the platform instead of against it. When I need a feature, I build it. When I don't, I don't.
This is the freedom that static promised but couldn't deliver.
Go Is Simply Amazing
I missed Go. I missed its speed, its simplicity, its compiled binaries
that just run. I missed goroutines, channels, and the standard library.
I missed the tooling -- go build, go test, go fmt. I missed
writing code that is fast by default rather than fast after optimization.
I had written about this journey before -- when I
migrated from Laravel to Golang,
and when I
built a bot-jailing middleware
for my Go apps.
Go is a language that gets out of your way. Static HTML gets out of your way too, but then so does all the power.
Conclusion
The switch to static was an experiment. It was the right call at the time — AI was weaker, deployment was harder, and my needs were simpler. But the world moved on. AI got smarter, deployment got easier, and my ambitions outgrew what static could offer.
I'm back on Golang. I have my framework, my database, my server, and my rules. And this time, AI can keep up.
Sometimes the old way wasn't broken. It was just waiting for the tools to catch up.
