Symphony's architecture was first concieved back in the 2000's and it's now starting to show it's age. While the architecture works, and works quite well for simple sites, and those that don't need heavy integration, it starts to have obvious flaws and gaps when trying to use it in a more modern way.
Back in 2009, cloud hosting was in it's infancy, PHP frameworks were few and far between and PHP itself was not as powerful and natural as it is today.
It's time to rethink the architecture, and think about how it should be in 2014.
- Symphony has no test coverage. Development is risky. We can never be sure that we haven't broken something previously as testing is done on an ad-hoc basis.
- Symphony is hard to test. Classes are tightly coupled and aren't stateless.
- Trying to develop custom code on Symphony is hard, the abstraction of fields and data means that retrieving entries is challenging and bloated, needing boilerplate code from multiple managers, or creating custom datasources.
- Standalone scripts often require the full Symphony stack to be initialised to work, this is inefficient and overkill.
- The delegate system is good, but it's inconsistent. In some cases extensions have more access to change things than the core code, and in others it's vice versa.
- Eat our own dogfood. We force XSLT on the frontend, but use custom PHP in the backend. Why?