The best Go framework: no framework?

I couldn&#x27;t disagree with this any harder. I&#x27;m a Java BE Engineer who joined a Go shop, so I have a direct comparison. Both are microservice environments for products of similar complexity. It is insane to me how much less productive Go is for your average microservice enterprise environment. I&#x27;m sure it&#x27;s great for systems programming or tool development. I like the simplicity. But the ecosystem is borderline useless for larger scale enterprise-y service landscapes. GRPC and Protobuf are overengineered and underdocumented, a lot of things are seemingly optimized for Google&#x27;s specific needs.<p>We are more people, we are more experienced and have a decent engineering culture. Yet we&#x27;re definitely less productive than the last average, traditional Java Spring Enterprise team I&#x27;ve been in. &quot;Circumventing&quot; a framework restriction (which rarely happens if you stick to good practices) is MUCH less effort than building things yourself from scratch.

This is one of the better things about Go and its community: eschewing frameworks like this.<p>Having an ecosystem of in-house libraries tailored to your products&#x27; use cases <i>is not</i> the same as developing an &quot;ad-hoc framework&quot;. Where I work, we have several languages deployed in our fleet of microservices. A couple have frameworks, and these frameworks are &quot;try to do it all&quot; types, complete with dependency injection and layer upon layer of abstraction intended to help engineers avoid &quot;needless&quot; boilerplate or what have you. They&#x27;re slow and difficult to debug&#x2F;troubleshoot for any case that isn&#x27;t anticipated by the frameworks, and even sometimes then. No, thank you.<p>Microservice architecture has its own problems, but these problems tend to be easier to reason about than the services themselves that use the frameworks.

You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now. You also better have stellar internal documentation because onboarding developers is going to be a pain otherwise.<p>99% of cases people are better off using a boring conventional web framework and implementing their actual business logic on top of it.

For junior developers reading this: frameworks are great, learn to love them, they will save you much time and stress when shipping real products.

The problem with not using established frameworks for building apps is that you&#x27;ll wind up creating your own ad-hoc &#x27;framework&#x27;. As your app (and the framework) evolves it becomes more feature-rich, it will be difficult for people to ramp up&#x2F;understand. They won&#x27;t be able to Google&#x2F;Stackoverflow for problems they&#x27;re having because nobody else on earth is using their &#x27;framework&#x27;. Then people will want features you&#x27;ve not implemented or thought about, so now you need a framework committee to decide what&#x27;s in, what&#x27;s out.<p>No thanks. Give me ASP.NET Core, Django, Spring Boot for a development organization with more than 1 developer.

Go having a standard library that is so good for building simple services is what sets it aside from all the other languages that have come out in the last while in the same space. It has a great collection of community libraries but I so rarely need to fall back to them as I can usually cobble together whatever I need to pretty easily just using the standard library.<p>It makes it easy to get started on a project as there is no time i need to spend thinking about the tools im going to use, its just provided all of them for me, in mostly high quality, relatively easy to use implementations of most basic things.

OP doesn&#x27;t ask the question that would have saved a somewhat straw-man general position on frameworks: <i>Why is it that Go lacks the familiar &#x27;widely adopted framework&#x27;?</i><p>OP could have written about the two different types of <i>code reuse</i> and why one lends itself better to Go: Libraries vs Frameworks.<p>Java has magical frameworks because we have a magical JVM and <i>first class</i> (as in baked into the language) metadata utilities at the language level. Java can <i>define &amp; load</i> new objects <i>at runtime</i>. Loose coupling? My god, this is as loose as it gets. In Go, you&#x27;ll need composition of processes to accomplish the same thing.<p>Code reuse at Go happens at the library and networked-but-loosely-coupled component levels. This covers a lot of territory but not things that are, in effect, &#x27;containers of components&#x27;. If you are in <i>component oriented</i> code sharing territory, Go is the wrong language. With Go, a framework can&#x27;t do <i>all</i> the magical stuff the other kids&#x27; FWs do, but you get most of the <i>pain</i> of using frameworks. It is a language issue.<p>in general: <i>Partially realized abstractions place greater demands on the language and its runtime capabilities than do partially realized composition (e.g. apis).</i>

This article makes an assumption: you know how to build the application better than framework developers do, which is not the case in general. Django docs are tremendous and you probably do not need most of it but in reality many of them cover real-world cases and do it in a good way. Sure, it may be a question of minimal code to implement it in go, but you have to know that you need this specific feature and you need to know how to implement it.<p>I&#x27;ve been doing small projects with go for a while and while I enjoy doing it in go (I like the predictability that types bring to me and the fact that I do not need to go through the tomes of docs to figure out something) I still feel every single time that I&#x27;m reinnventing the wheel.<p>The task is simpler with SPAs since all you need from go is a json api, but if you want to build something complete with htmx you&#x27;ll have to deal with many questions yourself. E.g.<p>- orm &#x2F; db access<p>- Signup &#x2F; login flow<p>- Emails<p>- Static assets versioning<p>- template helpers<p>- CSRF?<p>- Routing and reverse routing<p>- Page structures (you want to have the same field to look up page title, right?<p>- Partials for your templates (how do you do form validation in a nice and generic way)<p>There is a lot of stuff like this. None of this is impossible to solve, it&#x27;s quite easy in most cases actually, but it adds up and as I said, you have to know how to do it write<p>One thing for sure is that if you implement the concepts yourself you don&#x27;t need to abstract them away too much (or maybe you do if you want to reuse all the nice things in your next project). For me the most compelling thing is types and the fact that I&#x27;m not dealing with django&#x2F;laravel magic with long stacktraces that are meaningless to me, but I still return to thinking about doing next project with rails from time to time, just because I&#x27;ve implemented form validation hundred times already.<p>One good point about frameworks is about limitations - they are there and this is something that&#x27;s quite hard to overcome at times. Rails framework does things the certain way and if you want to do it differently you have to fight with the framwork or make an attempt to push things to upstream which I&#x27;m pretty sure is not the main goal of your project.<p>(edit: made list a list)

There&#x27;s something to say for getting in the habit of delivering microprojects with minimal dependencies and tooling.<p>I do most of my Python work with PyCharm on a Windows machine, frequently with poetry as a dependency manager, but lately I was writing a script for burning DTS-audio CDs in a single step on my Linux server (has the optical drive) and made the decision to only use the Python standard library and do it all in a single file I edit with vim. The result is 150 lines of code that spin like a top.<p>I went through a phase of doing all the problems on HackerRank and learned to love &quot;single-file Java&quot; and discovered that you can do almost anything in a single file except declare a public class (if it is all in one package, default access is all you need.) It&#x27;s not the usual way I do things but I like Java a lot more knowing I can write simple programs without maven, an IDE and all of that.

I literally have a medium-sized repo full of boilerplate required for a normal go web service.<p>It will be nice to one day factor it out into something I can import versus having to simply copy the template repo.<p>The stdlib is great but it doesn&#x27;t give you sessions, orm, csrf, sass&#x2F;minification, good templating, embedding, etc out of the box. You have to paste in lots of boilerplate to get those working.<p><a href="https:&#x2F;&#x2F;git.eeqj.de&#x2F;sneak&#x2F;gohttpserver" rel="nofollow">https:&#x2F;&#x2F;git.eeqj.de&#x2F;sneak&#x2F;gohttpserver</a><p>It&#x27;s WTFPL so feel free to cannibalize it in whole or part to save time. master is a bit outdated as I am moving it over to use uber&#x2F;fx:<p><a href="https:&#x2F;&#x2F;git.eeqj.de&#x2F;sneak&#x2F;gohttpserver&#x2F;pulls&#x2F;17" rel="nofollow">https:&#x2F;&#x2F;git.eeqj.de&#x2F;sneak&#x2F;gohttpserver&#x2F;pulls&#x2F;17</a>

Echoes back to Three fallacies of dependencies by Blake Mizerany<p><a href="https:&#x2F;&#x2F;www.dotconferences.com&#x2F;2014&#x2F;10&#x2F;blake-mizerany-three-fallacies-of-dependencies" rel="nofollow">https:&#x2F;&#x2F;www.dotconferences.com&#x2F;2014&#x2F;10&#x2F;blake-mizerany-three-...</a><p>Of course the only absolute truth is that there are no absolute truths, so no point of being dogmatic to the extreme.<p>Still, with experience I came to realise that dependencies carry their own weight, which has to be balanced with the weight of bespoke implementation (which can span the whole spectrum from &quot;obviously&quot; to &quot;NIH&quot;)

Yeah, Having built a web application serving 100K+ users in Go. First 2&#x2F;3 weeks were spent on making sure we were a framework. So new Modules could be added. New external calls were abstracted and also dealt with lot of circular dependency.<p>This was all fun and learning, but wouldn&#x27;t mind having a &quot;Flask&quot; or &quot;Express&quot; version of a Golang framework which took care of all the boilerplate out of the box.<p>We did try some existing solution to no avail like Tiny etc.<p>But ended up building a non-framework framework anyways especially to support new features&#x2F;modules and new devs coming it.

Go&#x27;s standard library already provides functionality that is provided by &quot;frameworks&quot; in other languages. So &quot;no framework&quot; isn&#x27;t actually a thing.<p>Also what I like most about Django and Django Request Framework is that it saves me so much writing and reading in almost every case. Not sure how you&#x27;re supposed to achieve that without something that looks like a framework or how writing ten times the amount of code is more sustainable and maintainable.

&gt; The easiest way is to start by putting everything into one file. You can start simple, defer some decisions, and evolve your project with time.<p>This is something that most even senior developers don’t grok. Default so called project starter scripts of the node world don’t help either.<p>The more structure you build before you know wth you’re doing, the more difficult you’ll make life for yourself down the line when you inevitably have to refactor code.

I dislike frameworks and prefer to avoid any dependency but the standard library, but coming from PHP, learning to write web apps in Go feels like being expected to write your own web server. Not sure how I feel about it yet.

I like fiber the most, but can use anything like echo (and past companies use only httprouter, gin, httpkit, etc)<p>as long as the codebase not overly layered, I guess any framework is fine<p>only need to split to 3 kind of layer:<p>1. serialization&#x2F;transport layer (codegenerated) -- framework goes here<p>2. business logic layer (one that unit tested), only input struct, transform&#x2F;process, and output struct (DTOs)<p>3. persistence&#x2F;3rd party layer (codegenerated too), add additional go source code file for things that wasteful to be codegenerated, only input struct, basic persistence methods or network calls, and output struct (DAOs) goes here<p>if using gRPC layer 1 already codegenerated, so only need to fill layer 2 with business logic and codegenerating layer 3.

I can&#x27;t tell if the article is recommending not using 3rd party packages or simple not to get caught up in an opinionated framework. I agree that opinionated frameworks don&#x27;t can be problematic as they don&#x27;t compose but can&#x27;t agree that with the statement that 3rd party libraries are bad. This is basically build vs buy argument favouring the build side.<p>A more measured approach would be to avoid 3rd party packages that aren&#x27;t very popular or are not particularly active.

I love writing no framework&#x2F;no lib backends in nothing but Node.js and TypeScript with some fp-ts and io-ts on top of that.<p>Node&#x27;s standard libraries (http, fs, etc) give you already enough to work with.<p>Sure, you&#x27;re going to have to re-implement plenty of things (e.g. file serving, which anyway isn&#x27;t great in node), and many other things but there&#x27;s plenty of pros:<p>- you can always understand how things work and change them to suit your use cases. That&#x27;s just not the case with external tools. Good luck figuring out the codebases or even be able to build them locally<p>- it&#x27;s much better for educational purposes to understand how things fit together and are supposed to work<p>The biggest con: security. Libraries and frameworks likely patch many vulnerabilities you didn&#x27;t even know existed. This alone pushes me off from this approach and instead I fall back to some bloated framework, but security is important.<p>The second biggest con: performance. You&#x27;re likely gonna do plenty of performance mistakes if you don&#x27;t have a good knowledge of how Node really works.

The main beef I have with frameworks isn&#x27;t actually with the framework. It&#x27;s teams fork lifting &#x2F; re-writing to the &quot;next best thing&quot; to fix a problem instead of polishing what they have.<p>You wind up with a perpetual revolving door of immature implementations instead of incrementally improving something with known flaws.

Having no framework comes with having no documentation.<p>If you select a framework and work in the same scope as the framework intends to, then you can onboard new engineers much more easily by telling them: We are working as the framework defines, look into the documentation and you will understand the basic architecture of our software.<p>Of cause, devs can maintain their own documentation, but I guess this usually is something that is not done very well.<p>My personal experience: As soon as a company started their software without a framework, it became a huge mess. While onboarding, I observed very bad architectural decisions and even very severe security issues.<p>I&#x27;d say, only go with no framework, if you are experienced enough to technically create an own (good) framework. From my observations, going without a framework was usually a decision done by young engineers.

Go without a framework and just the standard lib is already about equivalent to Python with FastAPI.<p>All you need to do is add a logger of choice, which will be different based on your architecture (one &#x2F; multiple servers) anyway.<p>You might want to add user auth, which is often an external server anyway.<p>Maybe you want some boilerplate &#x2F; codegen tool to add&#x2F;remove&#x2F;select objects from a database. But I personally don&#x27;t use that because it&#x27;s hard to optimize performance with those tools and SQL is already a good tool for it imho, don&#x27;t need an extra abstraction.<p>In summary, all you need is the standard lib and maybe 3 external libs in Go, because it was made in a time when an api was already pretty standard.<p>In other languages you need way more extra stuff to create an api, so the need for a framework is greater.

Same old topic.<p>I use gin. It&#x27;s not perfect, especially streaming (EventSource) is broken. But the rest has actual hand on solutions.<p><pre><code> ctx.SecureJSON() </code></pre> Not a single one of the other packages has something like that. Keyword: JSON hijacking protection. Yes it&#x27;s still a thing.

Been writing Go for my own pet projects and some production side projects for two years. Often resorted to &quot;small libraries&quot; like Chi, or SQL query builders.<p>Since GitHub Copilot, I ditched SQL query builders as all the scanning and repetitive work is handled nearly immediately. I also ditched Chi and handle routing myself. Same for logging.<p>The issue is spending time doing things that took one line before with a framework (e.g., parsing URL path params). But it&#x27;s actually satisfying.

&gt; Python has Django and Flask, Ruby has Rails, C# has ASP.NET, Node has Express, and PHP has Symfony and Laravel. Go is different: there is no default framework.<p>And this is the root of most problems described by author. If I start project on Python - I know that I can take Django and use it for at least 4 next years, spending one sprint a year tops to migrate to next LTS version. In Go only standard library currently gives me that kind of reliability.

Tired: Framework stuff.<p>Wired: Browser WASM (from Go source) that accepts commands over websockets to modify &amp; render the DOM. (Is this &quot;client hydration&quot;?) Tight integration with htmlx (for pizazz + ruthless efficiency) and Javascript (for rich text editors + other advanced widgetry). This may require full Go, if tinygo continues to lack reflection support.

I do not use Go but I share the approach. I avoid using frameworks until I have no other reasonable option.

Yeah, I think it might be a good option for experienced devs and it can also turn into a rabbit hole for junior folks. No silver bullet and everything depends on what you are trying to build. But yeah this discussion never get&#x27;s old :)

The graphic in OP summerize it pretty well. If all you need is something quick, and you don’t expect (or currently have the budget) to scale it a lot in the close future, then using a framework may very well be the best solution.

Was that just nearly 2,000 words and not a single fragment of Go in a post about Go?

A lot of people use go for microservices, and then you kind of need a framework.<p>And all the proto + protoc + protoc-gen-go + grpc + swagger&#x2F;openapi + json-grpc-gateway dance is… not easy to understand at first

It seems to me too many don&#x27;t know how big is Spring framework. You can do basically everything with OOTB starter. Enterprise projects are a breeze to develop with Spring Boot.

It&#x27;s funny, as someone proposing frameworks make sense in IaC (Terraform in my case), how the framework&#x2F;no-framework topic apparently never gets old.

This post embodies the majority of the Go community. “Let’s reinvent every single possible wheel”