A lot of go apps bolt together libraries yeah.

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.

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

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.

Composition is king.

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.

> Then interfaces like io.Reader and io.Writer mean you can pretty much use anything to read requests and write responses.

Yeah, that’s not the hard part at all. What about routing, converting from/to json/params/cookies safely, sessions, authz/n..

I'm a fan of gin over the builtins but:

> 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

Yes and that's frustrating