Why Kohana Rocks

Tue, October 5, 2010 5 Comments by Clayton McIlrath

I’ve worked with all the major players in the PHP framework space, and there are good and bad takeaways from all of them. My goal isn’t to bash on any of the others, because they all have fairly equal strengths and weaknesses.. some obvious and others not so much. This post will instead be focused on one of my favorite frameworks, Kohana.

Holy Light Footprint, Batman!

What initially intrigued me about Kohana was the fact that there were so many credible developers raving about it, and the size of the whole framework was under a meg! Previous to Kohana, I had been doing nearly every project in Zend, so a 60M footprint didn’t really phase me after a while.. and to see a framework that small made me immediately question how powerful it could really be; but within install and reading docs, I was off to the races building powerful web apps with such a tiny footprint.

After diving into the framework on a few large projects, I’ll sum it up this way.. Kohana is like the frame of a house.. which a framework honestly should be. It doesn’t include the drywall or insulation, but since the frame is so solid, yet lightweight.. the house can be shaped and formed in any manner then the extras can be added on. Compared to the modular home that Zend and CodeIgnitor offer, this truly is a different framework.

Yet something familiar..

The next thing I noticed is it felt a lot like CodeIgnitor, even though it was also very different. When I started seeing syntax similarities, I investigated to find that the Kohana team stemmed from the CI team a while back. What doesn’t matter is the politics of the separation, but what does matter is that Kohana was geared to utilize PHP5 from day one. This fact also made me beyond words excited to start building projects.. as I’ve watched PHP5 start to become more OOP but had yet to really see it in action or throw away my bad habits. Long story short, this boy has started OOP’ing everything because of it. Goodbye MVC and linear and hello HMVC and sub-classing.

But the best part

The complaint I hear the most is that “Kohana’s documentation sucks” which honestly just makes me laugh. What I love about Kohana is that it quickly brings out the fools of developers who need examples to write “Hello world” or tutorials to do CRUD operations on a database. Kohana is a very thoroughly and thought out framework, but yes.. it is lacking in examples. That’s because the classes and commenting in Kohana is meant to be the documentation. They built the manual right into the product, which is a feature we’re ALL SUPPOSED TO DO if we’re good programmers!! Am I right?!? I’ve found that looking up documentation is as easy as a shortcut search within my IDE and quickly grabbing what I need. I don’t use a book, no snippets or cheatsheets; because they’re all unnecessary.

Kohana PHP

Kohana is by far my number one choice when it comes to building most small to medium scale websites or applications. It’s proven capable time and again, and if my opinion counts for anything, then take my advice on this one.. you won’t regret it (unless you’re a bad programmer).

This entry was posted in Technology and tagged , , , , . Bookmark the permalink.

  • iridion9

    Yeah I understood now.
    I should be self creative and not looking for basic tutorials.
    Okay I’ll start experimenting.

  • Laurent

    The doc does sucks and the rare comments in the framework classes are certainly no substitute for a proper doc. I like the way Kohana works in general but it has a very steep learning curve.

  • Dev_and_mgr2012

    “The complaint I hear the most is that “Kohana’s documentation sucks”
    which honestly just makes me laugh. What I love about Kohana is that it
    quickly brings out the fools of developers who need examples to write
    “Hello world” or tutorials to do CRUD operations on a database.”

    Your smugness marks you as someone who never has to answer to a client on a tight budget or deadline while using badly documented tools.

    Kohana doesn’t bring out the fool developers,  it brings out the wrath of clients who want to know what the f&*K you’ve been doing all day to get their site up and running.

    You may get to waste your clients’ budget reading through source code to figure out how get Kohana to do basic things but I don’t have that luxury. I don’t have those kind of clients.

    The whole purpose of a framework is to make doing repetitive and routine tasks quickly and easily, so the developer can spend those scarce budgeted development hours on the hard stuff, the stuff that is the domain-specific problems. You know, the kinds of problems the client came to you in the first place and is paying you to solve. And struggling with piss-poor documentation ain’t one of them, not to a client.

    Do you understand the difference between reading documentation for a framework and reading comments in source code? It’s like the difference between reading Cliff Notes and footnotes.

    Kohana 3.2 is cool but the documentation sucks.  A developer is a fool only if he or she chooses this framework for a real-world project without being the kind of super-double awesome crackerjack developer with Kohana that Clayton McIlrath is. 

  • http://thinkclay.com Clay McIlrath

    Smugness? Never having to answer to clients?

    My friend, you’ve got it backwards. I have to deal with clients all day everyday, and if you watch me in any IRC channel, the last thing you will see from is smugness.

    I’m sorry that you have clients that micro-manage and small budgets, but that’s no reason to judge an article that praises a great framework. If you are well versed in a couple different platforms, you should be able to find the right tool for the project / budget, and if you cannot.. then turn it down. ExpressionEngine for example is a GREAT platfrom for cheap clients while still having the power of CI behind it. 

    I’ve pointed out the documentation, and the fact that the framework doesn’t document IS an advantage because it makes YOU find the solution rather than assuming the solution is the first example you come across in some documentation. This is also a VALUE ADD to your client as it means your code is a higher quality rather than the cheapest possible solution. 

    Furthermore, you don’t have to “waste your clients’ budget reading through source code” if you’re learning this framework on the side. Would you expect a doctor to learn new tools and principles on the fly or learn them first before bringing them into practice? If you respect your clients and aim to be a better developer, I would assume that you would master Kohana before ever implementing it on a project.

  • Steve Taylor

    The whole point of frameworks is so you can stand on the shoulders of giants. What’s the point if you have to go to the source and figure out how it works?

Browse by Category