It's funny; As I get better at any given language or system, I inevitably move away from frameworks into individual libraries more and more. I don't think it's to be effective as much as because it's fun to force yourself to learn the things you just don't when someone else has handled it for you; then again, I still use Rails in my day job and Ember for my side projects.
At the same time though, I love having a good list like this. If I could have this for Golang, it'd be a godsend. Having an upkept list of relevant libraries to put things together makes so much possible- if not for certain libraries existing, I don't know that I'd ever have embarked on many of the projects I do. They make me realize how much more is possible.
> As I get better at any given language or system, I inevitably move away from frameworks into individual libraries more and more.
Many programmers suffer from blank canvas fright, which is why they find comfort in frameworks. Frameworks tell the programmer "I've divided your problem for you; just put this kind of thing here and those other things there in those special files in this particular folder" and that somehow is supposed to make it easier for others to join a project (to the detriment of properly modeling the problem domain).
> Frameworks tell the programmer "I've divided your problem for you; just put this kind of thing here and those other things there in those special files in this particular folder" and that somehow is supposed to make it easier for others to join a project
Well, let's be honest - it kind of does make it easier. If I'm joining a Rails team, say, I can skim a project pretty quickly using body-memory knowledge of where stuff is likely to be.
Additionally, I can rely on the assumption that certain common tasks will be abstracted in well-known common ways. I'm not typically going to have to learn a new way to draw URL routes, or run-of-the-mill database queries.
I agree that this is inevitably "to the detriment of properly modelling the problem domain", but it's a real trade-off, not an illusion. Doing things, for example, in 'the rails way' makes parts of your life easier, and the judgement call is whether it makes them more easier than it makes other parts harder. Such is the nature of our line of work (and most others, come to think of it).
Certainly the framework-monolith is not as fashionable now as it once was; but that's hardly surprising, since domains change as well as libraries and frameworks.
At the same time though, I love having a good list like this. If I could have this for Golang, it'd be a godsend. Having an upkept list of relevant libraries to put things together makes so much possible- if not for certain libraries existing, I don't know that I'd ever have embarked on many of the projects I do. They make me realize how much more is possible.