The Case for Go Web Frameworks

Idiomatic Go is not a religion

I’ve noticed that the Go community is somewhat divided on the value proposition of using “full-stack” web frameworks, where everything you need to write a web application is provided “out of the box” and you need not concern yourself with lower-level libraries. Some Gophers complain that there is too much “magic” under the covers and that frameworks incur too much overhead. Full-stack, all-in-one frameworks do not comply with idiomatic Go. Therefore, web developers should “roll their own” and follow a “mix-and-match” approach.

I wish to disabuse everyone of this belief. My contention is that a good web framework can save you time and effort — time that you would normally spend on integrating and configuring the tools and libraries. This is time that could be better spent on writing your actual application, you know, on stupid things like UI design and implementation, business logic, testing strategy, etc.

The nature of the Go language is beside the point. The decision to use a framework is never constrained by language choice. Frameworks exist and work well for languages as diverse as Java, C++ [1], Haskell, Scala, Python, Ruby, Scheme, and Smalltalk. The fact that a framework may not be idiomatic Go is completely irrelevant.

A framework provides higher-level abstractions that hide the more complex details underneath. This is how you achieve greater simplicity and safety; the framework has already been tested and you are isolated from potential programming errors that you might make if you had to do your own integration.

Ultimately, a full-stack web framework is all about making you immediately and rapidly productive, allowing you to focus nearly all of your attention on your application and not on tool configuration and setup.

The Software Life Cycle

I find this argument spurious at best. The fact is, all software go through a life cycle. As the software grows and matures, it eventually reaches a point at which code maintenance is no longer economical. In my decades-long career, I’ve lost count of the number of projects where the software has literally been patched to death and only a rewrite can save the day.

This happens whether you use a framework or not. The minimalist, “mix-and-match” approach that many Gophers advocate will not avoid the eventual software attrition.

Business Reality

A well-chosen framework can dramatically lower the barrier to entry and make web development much easier. This is especially important in a team environment where you have developers of varying skill levels, or where team members are often replaced. Retraining is not an option and you need to bring new recruits up to speed as quickly as possible.

(With mix-and-match, developers new to the project need to delve into the custom scaffolding software that is usually poorly documented and laborious to read.)

There is enormous value in having a standardized platform upon which to build your application. This helps the team. The application has a well-understood program structure, which is easily communicated to developers from other companies. As long as everyone knows how to use framework X, a great deal of time can be saved.

Lowering the Barrier to Entry

You can’t even write a tutorial for how to write a web application using mix-and-match. By definition, mix-and-match exposes you to different libraries with different APIs, which in turn require you to write different glue software for every mix-and-match combination. So basically, a newcomer has to be thrown into the deep end and fend for himself. A primer on Go web development may serve as a general guide, but the newcomer still has to do all the “heavy lifting.”

A web framework does all of this heavy lifting for you, and it should document everything well so that you save time and energy.

What Overhead?

Image for post
Image for post

The Mix-and-Match Dilemma

On the other hand, you may choose to add new libraries to your mix-and-match configuration in order to satisfy the requirements. You may repeat this process for future applications. Eventually, if you refactor the code for reusability purposes, you will end up with your own mini-framework, one that is unknown to the outside world. As I discussed in “Business Reality” above, this is impractical.


If you’re a hobbyist or dilettante, “rolling your own” with the mix-and-match approach may be perfectly adequate. Business reality dictates that this will seldom be acceptable. Businesses always want deliverables on time; they want them as soon as possible. They don’t want excuses.

Choose your framework wisely and you will benefit both in the short term (with immediate and rapid productivity) and in the long term (with respect to team management and standardized development practices).

[1] I found this hidden gem of a framework for C++:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store