Go makes it easy to not use frameworks. Instead, small tool libraries used together achieve the same utility. The resulting applications are less complex, easier to reason about, and nimble in their modularity.

Frameworks are themselves collections of libraries. How do they differ from discrete libraries that have only one functional use, and how does using one or the other affect application development?

Frameworks are a base set of tools, and functionality, that all applications need. They consist of reusable code pieces that can be used on different projects. Frameworks allow for a quick start to a new project by limiting the amount of boilerplate code that needs to be written. Bundling code into frameworks make it easy to share, and to collaborate with others to improve the framework.

In addition to offering building blocks, frameworks aim to make using them as easy as possible through the use of abstraction and code generators. This insulates developers from the specifics, allowing them to focus on the business logic that makes their application unique.

Web application frameworks offer a full stack of options in building a webapp. From request routing to database abstraction and access. The goal of these frameworks is to be a one stop shop for everything a developer would need to build their application.

What is the cost of a complex framework?

Frameworks offer a lot of functionality, but at what point does the plethora of options become a burden? When does the large number of APIs become distracting and a detrimental. When does the tightly coupled framework become a burden to extending and customizing it to fit the needs of a developer’s application.

frameworks subject you to an increasingly bureaucratic interaction

Dave Cheney

The same features that make a framework appealing at first make them a burden in the long run. Over time frameworks grow; functionality is added, through the collaborative process, to make to help them become useful to a larger number of application types. Over time your specific application uses less and less of the available features. The rest come along for the ride.

While one can limit the impact of these features, in affecting build time, or load time; they add to the overall cognitive complexity.

With growth comes abstraction. Frameworks cover over the rough parts with abstraction, simple code generators, and easy to use functions. They build concrete implementations using information about data, and hide it away. Developers only see the tip of the iceberg, the little part they are allowed to use.

Libraries loosely joined

Large Go frameworks exist in Beego and Revel, but Go itself makes it easy to use small libraries to achieve the same result.

Libraries tend to be specialized blocks of code that do one thing. Which they do directly, without abstracting away the understanding of it’s function. In this way developers are better able to reason about the whole of their code. Less magic. Which I believe leads to better applications.

Abstraction can be problematic. When there are many layers, bugs are difficult to reason through, and solutions complex. Digging into an issues solution means winding your way through layers of code. As one function calls a method that calls a function that calls a function, and so on and so forth.

The Gorilla Toolkit’s mux like PHP-Slim is a single standalone routing package. All it does is match request URLs to handler calls. These tools do nothing else. They don’t even dictate the form that the business logic calls. They simply call a function. In their single isolation they are the place to look if there is a routing issue.

Small functional code libraries are reminiscent of the Unix philosophy.

at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves.

Or my favorite way to say it, which I take from the title of the David Weinberger book about the web, small pieces loosely joined.

By using small pieces tied together developers can make better choices about what they are using and not using. They are not tied to any implementation just because it comes with a framework. Decisions about which tools to use can be made based on an application’s specific needs. And later you can swap code out if needs change.

Go as a language, and the philosophical beliefs of it’s creators and users, makes it easy to write applications with small libraries. It reduces complexity by only offering what is needed. With fewer parts, and layers, applications lean towards being easy to understand. The focused, modular, nature of small libraries allows for straight forward refactoring and application evolution.