Então você precisa repensar o seu conceito de framework, pois a ideia e objetivo dele é justamente ser esta estrutura.
Isso é muito legal, não sou contra, só acho que não pode ser obrigatório.
aí que tá: eles não são obrigatórios, mas acabam sendo inevitáveis, como mencionei acima.
mesmo que você não adote um pronto, e acabe criando o próprio, você de repente se vê dentro de um.
dois anos atrás inclusive escrevi sobre isto: Apodrecendo seu software com rebeldia - /dev/Kico
Não quero parecer o chato insistente, provavelmente estamos mais concordando que discordando.
Acho que já disse mais no começo que é muito bom ter uma opção pronta de arquitetura. Acho que a discordância está mais no formato ou embalagem: eu preferiria que viessem como bibliotecas. A aplicação pode até vir montada, ter uma ferramenta que gera todo o scaffolding e esqueleto arquitetural é sensacional. Não sou contra isso e defendo o uso.
Mas o formato de componentes de biblioteca, que permite ao negócio ser mais dissecado e desmontado, era algo que eu queria muito ver. Taí uma ideia pra implementar, um “framework” no formato de bibliotecas encaixadas.
já existe: é o PHP atual. Eles tem o conceito de PSRs que é essencialmente isto: PHP: Do Jeito Certo
São padrões que você adota na escrita das suas bibliotecas para que possa haver interoperabilidade.
O que cria um “framework sem framework”. É muito interessnate.
Que legal, como estou há muitos anos longe do PHP (época do procedural), não sabia como andavam as coisas por lá. Vou dar uma olhada, e que isso vire um padrão de peso para competir com os arcabouços fechadões 
Isso é um sinal de que nossos preconceitos comuns contra a comunidade PHP são mais que infundados, a galera lá está em um nível de maturidade e inovação incrível!
eu nunca tive este preconceito aí não! kkkkkkkkkkkkkk
Também não, mas eles são comuns.
Pensei em algo sobre a má escolha.
Se um iniciante (ou mesmo experiente, por que não?) faz uma escolha ruim de framework e só descobre com a aplicação já bem grande, em produção, tendo que dar manutenção… O que é preferível nessa hora, que o framework fosse algo muito grande e amarrado (como a maioria deles é hoje) ou algo desmontável, controlado por chamadas feitas pela própria aplicação?
se estamos falando de iniciante, framework sem dúvida, pois todas as decisões técnicas sobre a inversão de controle já foram tomadas por alguém mais competente (a equipe que criou o framework)
Releia. Por hipótese, o cara fez uma má escolha. Quando isso acontece, o que fazemos? Dizemos: “kkkk, se fodeu, bem-feito, agora te vira aí”?
é… aí é reescrever mesmo.
esta ideia de reaproveitamento e portabilidade de código entre frameworks acho muuuuuuito otimista
É quase impossível, a menos que os frameworks sejam menos framework-like e mais biblioteca-like.
SGBSs têm rollback de transações, o git (CVS de maneira geral) têm os commits, agora uma escolha errada de framework provoca um acoplamento tal do código que equivale a uma prisão perpétua.
Sou a favor do framework como algo abstrato, a ideia de arquitetura X + bibliotecas K,L,M. Como implementação, não permitem rollbacks das más escolhas.
ô Éderson, algo me diz que você vai curtir muito este esquema aí do PHP, é bem legal!
acho que o que rola demais é que há cenários que são propícios ao framework. Exemplo: uma aplicação web.
Acho que vou comprar o livro da O’Reilly.
Aplicações web têm uma estrutura comum, mas aí eu tendo a me simpatizar com frameworks minimalistas do tipo Flask, Sinatra, Express.