The best Go framework: no framework?

This 100%. I think the people largely arguing for no frameworks have no idea what real productivity looks like at large scale engineering orgs. This mostly means you are not handcrafting libraries. There is a dedicated team who manages platform tooling including the frameworks/SDKs you use. Product teams may contribute to that but they will mostly be consumers. I always equate this to car manufacturing. I am not buying a kit car, I am not buying a hobby car, I'm buying a well engineered product from a large scale manufacturer. Frameworks and platforms fall into this category, especially for enterprises.

I think it's fine for small teams not to use frameworks, and maybe 200 person engineering orgs are made up of many small teams who just want to agree on a protocol rather than shared framework/platform but once the scale starts to increase you really need to start tightening up and implementing some better standards.

People constantly talk about not being Google, well let me tell you the people scale is all the same, the amount of legacy infra is all the same. If you haven't peaked into the depths of the messy multi-decade enterprise you have no clue. Your 4 year old company that you joined 6 months ago is no comparison to something with a legacy of 3 decades with 2k+ engineeers scattered across a disparate org trying to modernise in the cloud or whatever comes next.

Full disclosure: I work on https://micro.dev - a framework for Go

The lack of detailed documentation for grpc is pretty crazy considering how many people seem to be using it.

So many hours wasted investigating fringe http2 characteristics causing odd bugs on the platform.

I literally have a medium-sized repo full of boilerplate required for a normal go web service.

It will be nice to one day factor it out into something I can import versus having to simply copy the template repo.

The stdlib is great but it doesn't give you sessions, orm, csrf, sass/minification, good templating, embedding, etc out of the box. You have to paste in lots of boilerplate to get those working.

https://git.eeqj.de/sneak/gohttpserver

It's WTFPL so feel free to cannibalize it in whole or part to save time. master is a bit outdated as I am moving it over to use uber/fx:

https://git.eeqj.de/sneak/gohttpserver/pulls/17

This article makes an assumption: you know how to build the application better than framework developers do, which is not the case in general. Django docs are tremendous and you probably do not need most of it but in reality many of them cover real-world cases and do it in a good way. Sure, it may be a question of minimal code to implement it in go, but you have to know that you need this specific feature and you need to know how to implement it.

I've been doing small projects with go for a while and while I enjoy doing it in go (I like the predictability that types bring to me and the fact that I do not need to go through the tomes of docs to figure out something) I still feel every single time that I'm reinnventing the wheel.

The task is simpler with SPAs since all you need from go is a json api, but if you want to build something complete with htmx you'll have to deal with many questions yourself. E.g.

- orm / db access

- Signup / login flow

- Emails

- Static assets versioning

- template helpers

- CSRF?

- Routing and reverse routing

- Page structures (you want to have the same field to look up page title, right?

- Partials for your templates (how do you do form validation in a nice and generic way)

There is a lot of stuff like this. None of this is impossible to solve, it's quite easy in most cases actually, but it adds up and as I said, you have to know how to do it write

One thing for sure is that if you implement the concepts yourself you don't need to abstract them away too much (or maybe you do if you want to reuse all the nice things in your next project). For me the most compelling thing is types and the fact that I'm not dealing with django/laravel magic with long stacktraces that are meaningless to me, but I still return to thinking about doing next project with rails from time to time, just because I've implemented form validation hundred times already.

One good point about frameworks is about limitations - they are there and this is something that's quite hard to overcome at times. Rails framework does things the certain way and if you want to do it differently you have to fight with the framwork or make an attempt to push things to upstream which I'm pretty sure is not the main goal of your project.

(edit: made list a list)