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

The argument is often presented that an application can outgrow the framework used. As the requirements change and the application is extended, the code base can become rather unwieldy, as you try to work around the restrictions in the framework. It is said that you pay a “technical debt” for delaying the inevitable eventuality of discarding the framework and rewriting the software sans framework of any kind.

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

In reality, nearly all software projects have hard deadlines, as well as expectations of hard deliverables on schedule. These schedules are never generous, and they are almost always too tight. Given limited resources and limited time frames, businesses want tools that help them write their applications as quickly as possible, as soon as possible, and as economically as possible. This is where frameworks show their value.

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

The mix-and-match approach may not be difficult, per se, but it is time-consuming. A newcomer to Go web development must examine a variety of libraries in some detail to determine which ones to integrate into his application. Then he must write the middleware and scaffolding (or “glue”) software that integrates the chosen libraries. There is plenty of room for mistakes in this process.

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?

A well-chosen web framework can perform extremely well. There’s not a whole lot of “baggage” associated with it. For example, my favoured Go web framework, Beego, does very well on benchmarks (see TechEmpower). And it’s modular enough that you don’t need to utilize every available feature, thereby keeping your application relatively lean.

The Mix-and-Match Dilemma

Mix-and-match may work well for a “one-off” project, but if you write a number of different applications with different requirements and different mix-and-match combinations, you may be reinventing the wheel again and again, as you redo the scaffolding for each application scenario. There is no consistency. This incurs additional costs.

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.

Conclusion

A web framework is not a panacea. It may not be suitable for every conceivable situation. However, barring “edge” cases (for example, if you’re another “eBay” or “Twitter”), a web framework should satisfy the vast majority of businesses.

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++: http://www.treefrogframework.org/