For junior developers reading this: frameworks are great, but they will become an increasing source of technical debt, performance loss, and frustration. They will allow you to ship your first version faster, but every release after that will become harder. Not that it wouldn't be hard without a framework either, but frameworks make us feel that we need to work within their constraints rather than the constraints of our application and our users.
So learn a framework for whatever language you use, that's useful! But also learn to recognize when you are working against the framework and would be better served with a few libraries that you can combine in the way that you need. Frameworks optimize for certain use cases and expectations, and if your project is no longer aligned with those, it's probably a good idea to think about an exit strategy.
However maybe also learn to love a language that embraces them at the same time so you don't come away with a poor experience because of only trying a language that has poor frameworks (Go, JS/TS, etc).
Definitely try something like Python + Django, Ruby + Rails, Java/Kotlin + Spring to get a feel for what a mature framework can really do.
Then if you find you still don't like frameworks and the style of programming associated with them then sure, find a home in one of the ecosystems that are more inclined to roll it your own way.
Frameworks certainly aren't for everyone but using bad frameworks and then pretending all frameworks are therefore bad is highly prevalent among more recent developers. Try the good ones and then make up your own mind.
Also, this shit is harder than it seems, and it is painfully easy to introduce huge vulnerabilities if you don’t know what you are doing. SQL injections, CSRFs, etc can all be a problem if you go down a naive route.
I was fairly new to "modern" web dev, starting a project, and went with Django because I had more Python experience than anything else. But I found templates very lackluster and poor to integrate with all the different JS ecosystem libraries people are creating to do very cool things on the frontend. Unfortunately, hooking React up to Django is a mess and most people doing this are still 5 years behind in React-land. Are you going to hybrid some template and some React? Are you going to containerize your django and react build system together?
Basically, I wanted a robust frontend ecosystem, well integrated to a simple backend (no Spring, Django-Rest-Framework monstrosities).
That led to React -> Next.js -> Typescript backend -> the rest of the niceties around it like Prisma (ORM-ish)
Create T3 App simplifies all the setup into a template and is extremely fast to start building features. No js build system setup, no python virtual envs. tRPC is an optional nicety.
I don't like using frameworks but I feel this comment is really important. I spent years using frameworks in other languages. Understanding why things are structured the way they are and what works for my needs and what doesn't.
Also when working with a team the value of having a lot of documentation, stackoverflow questions a google search away and an obvious way of doing things seems incredible valuable.
Does building your own microframework brings joy and a sense of accomplishment? yes it does. Does that correlate with accomplishing business needs. Not necessarily.
How about offering real counter advice instead of just saying its bad advice?
Going to have to also agree with the OP. Frameworks are great for the majority of real world cases. There are definitely cases where specific optimizations are required and maybe a framework is not best fit but those are rare.
Lets try to steel man your disagreement though. Having worked in larger orgs I believe there is a trap that some fall in when using frameworks. Ignoring what is happening inside of the plumbing of the framework and ignoring why the framework is doing it. From that perspective you can fall in the trap of not having mastery of domain and it can limit your career in the long run.
On the otherside my argument is that frameworks provide immense value to orgs of all sizes. Even for a single person team there is value because you are not wasting your time on problems that are not part of the business. You should understand how the framework works in the long run though. A lot of these patterns carry over between frameworks and languages, mastering your first one will open a lot of doors in the long run.
"Wasting your time on problems that are not part of the business"
How much time?
Sometimes a task that takes X time and seem unrelated to your "main" task, actually increases your productivity when doing the main task.
A prime example is sleeping when trying to build muscle and lose weight.
On a surface level, sleep is a waste of time: you should be in the gym lifting weights or out there running/cycling/swimming. But actually no. Sleeping improves your results, and improves your performance on your workouts.
I'd argue there's a similar dynamic here.
Working on the lower levels of your problem might seem like a waste of time, but it's actually not. If nothing else, you feel more enjoyment from your work. Being engaged with what you do and not being engaged is huge.
Another problem that often occurs when you are always only working in the "high level" is you have no idea how to do anything well unless the framework does the heavy lifting for you. As soon as you step outside of what the framework was designed to help with, you are lost and have no idea how to approach the problem. All your approaches are half-assed solutions. You see this every single day on "big teams".
For junior developers reading this: frameworks introduce additional complexity (especially ones with obscure dependency injection), learn how to use different tools properly and analyze when they should/should not be used. Learning your language properly (and carefully selecting when a framework makes sense vs when it doesn't) will save you much time and stress when shipping real products.
There's a time and place for framework/no framework, though I'd err on the side of not introducing a huge framework until it's actually needed.
Source: I work on a real, shipped for 3 years, SaaS product primarily written in Go (multiple services). The primary applications are framework-less, but some of our operators make use of kubebuilder (which certainly would qualify as a framework).
For junior developers reading this: frameworks are useful if the tradeoffs they make are right for your current situation. They are good tools when used wisely. However, developers who are heavily invested in a specific framework will often try to sell them as "great" but recognize that their investment biases them and may result in "when all you have is a hammer, everything looks like a nail" syndrome, causing these one-trick ponies to advocate their favored framework even in situations where other frameworks or even no framework is a more sensible solution.
