I did originally try to leave this as a profile comment under your link but it was too long (hah) so I will leave it here. Thoughts based on looking at the repos you linked me to.
I get that you’re going for Mezzio’s views philosophically but for me that’s not actually a great DX. I don’t particularly care that every module is swappable because I’ll go with whatever everyone else goes with - because it’s convenient and means others will find it familiar (which is a key requirement for me).
As I get older I find I care less about the intellectual purity and correctness standpoints in favour of “I need to do this very typical thing like all the other things, what’s the quickest and easiest way to do that” because often my clients want it done affordably, it’s not about the “perfect” but being good enough I don’t need to worry about it.
Laravel lets me get going, stays out of my way with a consistent approach for the stuff I don’t generally need to change, and lets me easily change the stuff I might (but rarely do in practice), and means I can hand it over to someone else to maintain without explaining how the framework works.
It’s like the discussion that happened ages ago on SMF about making it hot-swappable to use Silex/Slim/Symfony and others, and my point is that while that’s technically cool, it doesn’t actually solve the real world problems, while engaging in a lot of effort for the sake of it - yes, modular is great, yes letting devs pick and choose is cool, but only if it doesn’t get in the way of the users. Such an SMF for example front loads the conversation with “which one do I use” (as opposed to picking a sensible default that everyone can adopt) and forcing certain cross-combinations of “well I want this because I want to use that and that depends on it, but that then rules out this other thing I wanted to use”, which you’d think shouldn’t be a problem with well-architected interface-driven code but the reality is that virtually everything ends up reverse engineering the interfaces to fit the implementation anyway, so all the good SOLID stuff (esp the L) goes out the window, and you have this multi-headed hydra that is conceptually cool but ultimately frustrating to work with.
Bottom line: I think the approach you’re taking has an audience, just an audience who has a different set of concerns to what practically and realistically affect me or what I want to build on. And for that audience it delivers in abundance, it’s just a shame that I don’t really belong to that audience any more.
I get that you’re going for Mezzio’s views philosophically but for me that’s not actually a great DX. I don’t particularly care that every module is swappable because I’ll go with whatever everyone else goes with - because it’s convenient and means others will find it familiar (which is a key requirement for me).
As I get older I find I care less about the intellectual purity and correctness standpoints in favour of “I need to do this very typical thing like all the other things, what’s the quickest and easiest way to do that” because often my clients want it done affordably, it’s not about the “perfect” but being good enough I don’t need to worry about it.
Laravel lets me get going, stays out of my way with a consistent approach for the stuff I don’t generally need to change, and lets me easily change the stuff I might (but rarely do in practice), and means I can hand it over to someone else to maintain without explaining how the framework works.
It’s like the discussion that happened ages ago on SMF about making it hot-swappable to use Silex/Slim/Symfony and others, and my point is that while that’s technically cool, it doesn’t actually solve the real world problems, while engaging in a lot of effort for the sake of it - yes, modular is great, yes letting devs pick and choose is cool, but only if it doesn’t get in the way of the users. Such an SMF for example front loads the conversation with “which one do I use” (as opposed to picking a sensible default that everyone can adopt) and forcing certain cross-combinations of “well I want this because I want to use that and that depends on it, but that then rules out this other thing I wanted to use”, which you’d think shouldn’t be a problem with well-architected interface-driven code but the reality is that virtually everything ends up reverse engineering the interfaces to fit the implementation anyway, so all the good SOLID stuff (esp the L) goes out the window, and you have this multi-headed hydra that is conceptually cool but ultimately frustrating to work with.
Bottom line: I think the approach you’re taking has an audience, just an audience who has a different set of concerns to what practically and realistically affect me or what I want to build on. And for that audience it delivers in abundance, it’s just a shame that I don’t really belong to that audience any more.
I mean after all, I just wanna build cool stuffz 
