This has been my experience: In creating a Framework which follows the general principles of a Symfony application (since we're all familiar with Symfony) we've

This has been my experience: In creating a Framework which follows the general principles of a Symfony application (since we're all familiar with Symfony) we've ended up with interfaces that closely mirror what we're used to in Symfony. 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)