This question is more for @bastianallgeier. Bastian, I’ve been working in Laravel recently trying to learn more about MVC. Although I like the MVC way, I don’t care for the folder structure that I’ve fought so hard to stay away from — reminds me of WP. One thing that I’ve noticed in the PHP community is how much Composer is being used to pull in libraries of all sorts with ease. In the near or distant future, will Kirby apply PHP standards (PSR) and allow other libraries to be easily implemented with Composer? And if not, why not?
PSR, no. This is just too complex for the simple structure of Kirby.
But Composer support is definitely planned for the future. I actually already implemented this, but it has to be improved and finalized to become part of a stable Kirby version.
There are a couple of reasons behind the decision not to go for composer so far. (btw: the toolkit is available via composer)
- building everything around composer packages often leads to huge repositories with many nested dependencies. It’s the same issues as with node packages. That’s not a big deal when you build a bigger application, but for something small and simpel as Kirby, it can get too big and heavy quite easily.
- Namespacing is awesome, but also very frightening for PHP newbies. As you know I try to make Kirby friendly especially for those without any PHP knowledge or those who just get started. I always felt that it would make Kirby seem much more complex when I’d introduce Namespace throughout the project. Especially the toolkit would be much less easy to use out of the box in my opinion.
- I tried to solve the namespacing issue with class aliases but that lead to quite some performance issues, which was a dealbreaker.
- Splitting everything into tiny little composer packages would have also led to more performance downgrades by adding more and more autoloaders.
- The step from Kirby 1 would have been huge. Kirby 2’s architecture has already become quite more complex and I wanted to avoid at all cost to make it even more complex.
So in general it was a decision that was not easy because there are of course also a couple downsides, but I felt it would be the best for Kirby. I’m not sure what will happen with Kirby 3. As Lukas already mentioned there are a couple plans to make it more composer friendly without messing up the structure, but it still needs more work.
5 Likes
Thank you for taking time to write in detail. I really appreciate that. When I first strayed away from Wordpress (for several reasons outside of its bulk structure), I was excited to have found that Kirby did many things much easier while taking a minimal approach. I believe that’s why Kirby is so successful to users coming from other CMSs. Kirby has motivated me to learn outside of its structure to more complexities like MVC which I’ve found to appreciate. So forgive my selfishness if I’m making suggestions that’s outside of Kirby’s vision. I am glad to see that you’ve introduced routing and controllers, however. That’s huge and a big leap forward. This is a great platform you have built and I can always look elsewhere to learn further while also enjoying Kirby.