Quick takeaways
- Frameworks promise productivity but often lead to issues as projects get larger and more complex.
- The Go community prefers small, focused libraries over frameworks due to Go's design philosophy influenced by Unix principles.
- Watch out for risks using frameworks like vendor lock-in, deprecation, and costly migrations that can take months.
- Explicit code is more maintainable than magic framework abstractions.
- Choose your approach based on project size and maturity - frameworks might work for prototypes, while modular libraries are better for long-term projects.
Introduction
In this episode of the No Silver Bullet podcast, we discuss frameworks in Go and when they're useful or problematic.We talk about why the Go community generally avoids frameworks compared to other languages, and how small, modular libraries are often preferred in Go development.
We share our experiences with frameworks across different projects, including tradeoffs between productivity and long-term maintenance.
Notes
Quotes
The happy path is easy enough, but the happy path is usually not the hard part of software. We often overvalue how much effort the boilerplate requires. - Miłosz
Framework knowledge tends to become out of date. You can spend days or weeks learning something about a framework, but it can be outdated. And if you switch to another programming language or company, a lot of effort that you spent to learn stuff will be just wasted. - Robert
It's more important to learn even-driven architecture because you learn the theory behind it and how it works in general - it transfers better to whatever you will do later. Focus on timeless skills like how to split modules in your application, how to make it decoupled, how to write business logic so it's easy to read and modify. - Miłosz
The Go language is heavily influenced by Unix philosophy - write programs that do one thing and do it well, write programs that work together. It's visible in Go's standard library. This is why Go promotes building independent components that you can connect together. - Robert
You need to be careful not to go too far with foundations. It's better to start with some modular libraries, have some reasonable setup in place, but don't go too crazy with it. Most of the time you'll need to refactor the project anyway, whatever you do, because it can change drastically. - Miłosz
One big decision at the beginning may cost you six months of work later. Understanding if something is tightly coupled to your application is simple - just think about how easy it would be to remove it. - Robert
Full episode notes: https://threedots.tech/episode/when-you-should-not-use-frameworks/
