[bauerd]

You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now. You also better have stellar internal documentation because onboarding developers is going to be a pain otherwise.

99% of cases people are better off using a boring conventional web framework and implementing their actual business logic on top of it.

[infecto]

This has always been the sticking point for me when I am wanting to try out new frameworks. When starting a new project I used to get excited on the idea of using a lean barebones framework, only to realize later on the boring bits that I had to figure out/implement or rely on some third-party library that may not stay up to date with best security practices in the future.

[jerf]

"You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now."

In Go, not necessarily, because net/http actually is what many languages would call a "minimalist framework".

There's a sense in which pretty much everyone here is right. You do need a framework in the general sense; you can't expect to just throw someone a TCP socket and get reasonable work out of them because the web is very complicated nowadays. But the reason why you can "do without a framework" in Go is that it is already a minimal one of its own, and in particular, that "minimality" focuses on providing a mechanism for composing various bits of HTTP code together.

So, do you need CSRF protection? Go grab this: https://pkg.go.dev/github.com/gorilla/csrf It operates with the integrated net/http Go framework to provide CSRF protection. You are objectively not abandoning the ability to have community-written CSRF protection when you go "frameworkless" in Go. Gorilla in general provides lots of mix-and-match pieces: https://www.gorillatoolkit.org/ , like cookie signing: https://pkg.go.dev/github.com/gorilla/securecookie

I think calling Go "no framework" is kind of misleading, because I get what you're saying, but the standard library is not the "no framework" option. The "no framework" option is more like using https://github.com/valyala/fasthttp , which is its own server implementation with an incompatible API that does in fact remove you from the community code, other than the code that works only with that server.

Don't over-read my post. I am merely saying that Go essentially ships with a minimal framework and so it is misleading to say or think of it as being "frameworkless" (and that is a criticism of the original link, yes), not that it is mandatory to use only that "minimal framework" and all other things on top of it are a bad idea. There are times and places to want large, preconfigured packages of additional functionality. But if there are times and places where it is not desirable, Go does come with a minimalist option by default. It is a pretty good, not-very-opionated option suitable for a standard library, where development is slow and there's not much room for experimentation in what a "full" web framework should look like.

The standard library minimalist framework even makes the other frameworks pluggable. You can, for instance, write an API website, then realize that if you need a conventional HTML website, you can plug in a framework for that part, but leave the API part as-is, simply by routing the API URLs to the existing API code while routing the HTML website to the http.Handler provided by the framework. Even "not using an additional framework" is not the commitment it may be in other environments, because the net/http foundation is still there.

[grose]

Well said. The 'no big framework' thing works for Go because the Go standard library defines a common way for dealing with HTTP. The difficulty, then, is identifying 3rd party packages that play well with the rest of the ecosystem.

You can see the opposite in projects like Echo, Gin, Beego, etc., that eschew the standard library to various degrees and try to build the kitchen sink themselves. Sometimes this works! Echo is very popular, despite having nonstandard handlers and context. An absolute Go newbie is probably going to have an easier time using it than trying to pick out the best collection of libraries themselves.

I would love to see more 'blessed stack' collections that tie together good libraries such as this one: https://github.com/mikestefanello/pagoda

[dinkleberg]

I agree with you that not using a framework requires you to think more about these things, but if you’re using a routing library like chi or gin there are plenty of libraries adding such functionality to them.

[bauerd]

Yes you can put in the work and zip a bunch of libraries up into your own home-brew framework. But I doubt it's time worth spent for most teams.

[valenterry]

I think that actually depends on the programming language. With golang, such a task is much harder because integration is more errorprone and requires more plumbing, e.g. due to missing generics (until recently).

For other languages that is different though.

[nprateem]

So then you have your own framework again, but with no coherent docs.