The standard library defines some decent interfaces already around HTTP handling and SQL calls. Most libraries are built to integrate with them. Then interfaces like io.Reader and io.Writer mean you can pretty much use anything to read requests and write responses.
This means that usually you're composing libraries and some application code together, rather than building everything on top of some jack of all trades framework. You get to choose the best tool for each job.
> What about routing, converting from/to json/params/cookies safely
All supported out of the box with the standard library. It's also table stakes, and not the hard part.
> sessions, authz/n
This is where you need to step out of the standard
From what I've seen yes. So in practice every go app is a custom & unique framework. Same problem as react. This was also the norm in php until laravel got popular a few years ago.
IMO it's a rough way to make a web page but people keep doing it so it must have some advantages.
Not a go dev but I have dabbled. I get the impression that the sweet spot for go is not in building standard crud web apps but for specialised network services and tooling. For those reasons big heavy frameworks don’t seem popular.
It’s not that we roll all our own stuff it’s just that most of us avoid opinionated frameworks. Example I’d wager most go backends are using gorm or sqlx because rolling your own orm would be insane for most
