So long Kohana

Anyone who’s followed the progress (or lack thereof) with the Kohana framework probably wasn’t surprised by yesterday’s announcement of its End of Life. As someone who was a loud proponent of Kohana (see my GitHub if you don’t believe me), I wanted to put down some reflections on the passing of my “weapon of choice” framework.

Kohana is the reason I’m a good developer today, I have absolutely no doubt about that. I did some of my very best work using this framework, and it remains the only one that really felt aligned to how I wanted to build things.

It taught me important lessons. It taught that writing PHPDoc comments will always be a good thing by rewarding those that did with dynamically generated API docs for my classes as well as it’s own; see userguide module. It taught me that PHPs autoloader (long considered a weakness of the language) could be turned into something innovative and insanely powerful (see cascading file system). It taught me that speed and real world uses trump over-abstraction every time. It taught me to write full APIs; getter and setters on everything, array or single values for setters etc, and that trying to force developers to use your class “your way” is counterproductive. Kohana’s use of single functions to do get and set (pass a value = set, no values passed = get) still feels insanely clean to me, and I wish more people would use it as it makes APIs vastly more “fluent”.

But I’ll tell the other side too. Unit testing was never a pleasant experience, with new versions of phpunit often breaking your tests for weeks until the core team fixed it. And Kohana’s use of statics is seen by some as a weakness. Personally I always felt there were very few cases where statics are used without merit, but that’s just my opinion. Also it’s lack of documentation for newbies (step by step user guides, cookbooks et al) was a running joke amongst its users.

The attitude of the core development team needs to be called out too. Whilst the project was at its height, the strong and focussed leadership, with a clearly defined roadmap and vision was a godsent. When the team abandoned it almost overnight, that exclusionary attitude to development became a millstone, with those wanting to contribute (myself included) having no idea where to begin, or even knowing if such contributions would be welcomed.

All that being as it is, I always felt this was a framework for “real PHP engineers”. It embraced what made PHP strong (fast, auto loader etc) rather than trying to force it into a Java-esque soup of subclasses, or an amateurish mess of PHP3 and magic.

Judging a framework by its docs (as so many did with Kohana) is simply the worst way of evaluating a framework. And yet we still see people do it today, with “prettiest website and baby’s first steps guides” often winning over genuine exploration of a projects philosophy and architecture to see if it’s the right tool for the job.

But I digress.

There’s one more reason why I think the passing of Kohana is particularly significant. In my opinion, the cascading auto loader will never happen again. Now we live in a world of PSR-0 and the FIG, frameworks that pursue different avenues of core behaviours are either shunned directly by the bleating masses (“lol y u no PSR n00b?”) or indirectly by not being compatible with Composer, therefore effectively dead in the eyes of the community. It worries me that we’re moving away from a blank canvas (albeit wild west) and into a very tunnelled world.

Consider that three of the most popular frameworks are based on the Symfony HTTP Kernel (Silex, Laravel and Symfony itself). All require PSR-0 and all require composer. Fine, that’s absolutely their choice, and I’m not suggesting that being based on the Kernel is a bad thing, far from it. I just want us as a community to make sure there is room for innovation outside of this set menu. Judging by the downright poisonous attitude that is displayed towards other component libs (Aura for instance), I do worry about the future of the PHP space.

But I won’t go into more of that here. This is a tribute to Kohana. I’m sure it’ll live on as Ohanzee in some guise, but the framework I have known and loved has reached the clearing at the end of the path.

I, for one, will miss it. So long old friend.

  • philsturgeon

    While I agree with a lot of this (Kohana was a great framework) I feel a little confused about some of the remarks you make about PSR-0 and other modern frameworks.

    There is a reason the bleating masses require PSR-0 support these days. We (the FIG) never really expected it to be such a war-cry by the community, but once you give people a taste of easy inclusion of PHP code then they’re not going to go back on that.

    Imagine. You have 90% of your dependencies autoloaded, then somebody releases a package which is not only PSR-0 compatible but does not use Composer. Urf. So I have to find somewhere to put that file and autoload it, then check back every few weeks to see if they’ve updated it?

    You can see why people shun that.

    PSR-0 has literally zero impact on the frameworks, packages or applications you make. The cascading file system was great early on, but these days it is a bit od a dodgy hack which can be implemented much better with namespace aliasing and that again allows you to override stuff AND use PSR-0 if you wish.

    > Consider that three of the most popular frameworks are based on the Symfony HTTP Kernel (Silex, Laravel and Symfony itself)

    You have picked three Symfony-based(ish) frameworks and pointed out that they are based on Symfony. That is not something to be scared of, that’s just a basic fact. Two were made by the same people, so… :)

    There are _many_ other popular PHP frameworks not based on that. ZF2, Phalcon, SlimPHP, etc.

    > Judging by the downright poisonous attitude that is displayed towards other component libs (Aura for instance), I do worry about the future of the PHP space.

    I’m not sure what you mean here? Many are big fans of decoupled packages. While some of the Laravel community might scream at people like me whenever I suggest that framework agnostic code is a good idea, most PHP developers are starting to get it as a concept.

    PHP components are very much the way forwards. Frameworks at this point are just a predefined application structure, and a house for you to home your components. Don’t buy a house because these days they’re all built on quicksand. Rent, and move around when that shit sinks, or you get bored, or you need a bigger house, or a smaller one, or… fuck this analogy. You get it.

    • alexgisby

      Hi Phil,

      Thanks for the reply :)

      I wouldn’t dare suggest that PSR-0 is a bad thing, and I’m a great supporter of the FIG’s stance of; “this is how we work, if you don’t like it, don’t work to our standards”. Without the work of the FIG, we couldn’t be in the position we are today where we can actually realistically do without a framework altogether because there’s so many high quality components you can stitch together easily (thanks PSR-0 et al). This isn’t just a good thing for the PHP community, for me, it is easily the best thing that has happened to PHP in recent years.

      I suppose my argument about autoloader is nudging invalid anyway. Whilst composer prefers PSR-0, the work with PSR-4 proves that should better ways of autoloading be found, they can be included. Let’s not pretend like it’s not a barrier (again, see PSR-4 which I know you’re intimately aware of ;)) but it’s not an insurmountable problem.

      I have to disagree on the CFS being a hack. Hack makes it sound like it was a bad thing, when there are specialist apps I’ve written that would have been horrific messes without it. It perhaps only looks odd these days because we’re used to the PSR-0 world? I dunno.

      Aliases etc are indeed a way to reproduce a level of the flexibility that the CFS provided, but me personally, I loved the fact that the class name still corresponded to a physical file rather than an entry in an array/config file. But this is me getting super picky and almost certainly isn’t as valid a complaint as I believe it is ;)

      The Aura comment was around the point that you allude to where framework proponents are still dead set against component based development. But you’re preaching to the choir on this one; at work currently I am pushing heavily for our next-gen apps to be written using Silex (or even the HTTPKernel) as a base and then adding components as we go, rather than trying to cut down (or ignore parts of) an existing pre-baked framework. This approach relies heavily on PHP devs acting like engineers though and properly evaluating their choices; something that large proportions of any large programming community are less inclined to do.

      It’s tremendously exciting to be at a point in PHP’s history where such an approach is possible though. It really is.

      (and yeah, I was being slightly cheeky including those three frameworks, it’s just the three I’ve spent a lot of time arguing with people about ;))

      • philsturgeon

        Ha! Yeah I’ve heard people acting like they are the only three to exist too.

        The framework bros and the component gangs will meet in the middle soon enough. It’s amazing to be at a point where frameworks CAN be made of components, and even have them share them. There was talk a while ago of Zend and Symfony picking one of their YAML packages and just both using that, which is AWESOME.

        As for CFS, I am not looking at it retrospectively now and thinking “weird”. I remember thinking the same thing years ago.

        They were trying to find a way to replicate CodeIgniter with its $this->input being potentially MY_Input or CI_Input. They just had some empty files being loaded and aliased to achieve this.

        Maybe these days its not as gross thanks to Zend Optimizer being rolled into 5.5, but it is still a rather odd way to go about doing something. Even with their cache, I always (for as many years as Kohana had their CFS) thought it was a weird solution. VERY clever, but definitely weird.

        Thanks for getting back to me on that one. I wanted to play devils advocate a little bit to clear up some points for future readers. :)

        • alexgisby

          Ok, well we can agree to disagree with the CFS ;) If I’m brutally honest, then yeah, first time I saw all the emptyish subclass files I was a bit flummoxed, so maybe it’s not the shining beacon of awesome that my rose tinted glasses are telling me ;) But the fact that it was a mental solution to the problem is a benefit for the PHP community at large; the success of the CFS had some steering on the PSR autoloader discussions, even if it was “holy crap, let’s not do that”. As long as we can retain that spirit of the insane along with the “obvious routes” in this new(ish) Composer universe, my concerns around that, and the Symfony components etc largely disappear :)

          Thanks for the devils advocate approach, it’s always appreciated. Not being open to questions or criticism isn’t engineering; it’s religion. And smart people are more fun to talk to.