The end result has its own pros and cons:
* We don't get the brute-force security you get when millions of websites are running the same framework
* Our implementation is much faster (and there are many fewer memory leaks, as that was a core concern), as it only has the features we actually need.
* Without middleware layers for cross compatibility there are fewer abstractions, this allows the entire framework and application to be reasoned about with a lot less magic obfuscating the code which is actually running.
* If something is slow, it isn't an opaque problem of "symfony being slow", it's "@helldritch can you take a look at \App\Framework\DB\Query\JoinHydrationStrategy on line 112? If you unset the fields you no longer need, the hydration runs in linear time - much quicker when joining collections of Users against the Groups they're in)" <-- an actual message from our Discord.
* Each feature takes a little bit longer to develop (as the Framework needs the implementation before the application can use it)
That's true only if you're looking at it through the lens of the current paradigm; for instance, assuming that you need "typical" routing, HTML templates, reactivity, etc. But, these each represent just one way to solve the problems they address.
So, "the right way" here is kind of self-referential and assumes there's no better paradigm to be found. The current crop of frameworks are conceptually all very similar and represent just one more iteration. We'll move on to a completely new paradigm at some point.
Nope, existing frameworks are designed to solve the problems in 100,000 different applications across every domain known to man. Your "framework" (which if you're doing it right is probably more like a set of patterns and a carefully selected set of libraries that do one thing well) solves your own problems, and only your own problems.
If something tailor made to solve your use case specifically looks exactly the same as something like Django, then you're either Google or you've overengineered it.