TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
2013: The Future of Kohana?
  • I’m wondering about the future of Kohana. I can see that development has slowed significantly since I was last here (back in July 2010) and it seems the future of Kohana is being questioned more and more these days…

    At the same time, I see that the download page says that support for the latest version (3.3.1) will only last until November 2013! If I’m starting a new project today, where the development will last a couple months, what am I supposed to do/use?

    I first started using Kohana back in mid-2010. After trying CodeIgnitor I quickly switched to Kohana, built a site using 3.08, upgraded to 3.1 and now in present-day, it’s currently running 3.2.2. It runs very well, super fast, it’s easy to maintain and I have no complaints…

    The Kohana Framework made sense to me from the start. (I don’t use ORM, I setup my database with InnoDB tables, foreign keys, procedures, lots of triggers, etc. and I prefer to use my own queries.) The lack of documentation (as some people say) never bothered me either. The code is commented so well, (and all my code is commented like crazy too), that using the userguide module was, at least to me, better than having to read any documentation…

    In fact, I like Kohana so much that when I was writing a plugin framework for my WordPress site, I modeled it after Kohana somewhat… I’ve customized that WP site so much (custom plugin with various “modules”, custom theme, etc.) and I was about to customize it further (to change the way WordPress handles some things, and add some functionality) when it occurred to me that I spend so much time fighting WordPress (writing workarounds and hacks) that maybe it’s time to just move it off of WordPress already. I don’t need to tell anyone here how messy WordPress’ code is, slow, inefficient and cumbersome…

    So my situation is that rather than constantly fighting WordPress, I’ve determined that I should just use a framework and move the site off WordPress. Apart from moving some existing content though, you could say it’s a “new project”. In this case, I don’t mind starting from scratch and it probably makes the most sense to do so.

    And once that’s done, my original Kohana site is also due for a makeover. I have a lot of changes I need to make to that site (that have been pending for a while now) and I’ll be adding a lot of new functionality (and integrating Stripe) at the same time.

    So the question is, what framework should I use?

    Though I used to make a living as a web developer (to support myself while going to college for music), I’m not a full-time developer (music is my day job) so I don’t have tons of time to learn “various” frameworks. While that investment in time makes sense for a full-time web professional, in my case, I prefer to learn one framework very well than to use many of them poorly. The problem is, I have a love affair with Kohana that’s hard to split away from, but at the same time, I don’t want to invest all my time with Kohana if the framework is eventually going to die, which seems like very much a possibility. Or am I wrong? Is this rut just a temporary thing with a foreseeable end in sight?

    I’ve started looking into Laravel, Rails, even Django, though not very thoroughly by any means. Staying with PHP has its pros and cons just like moving away from HMVC or Kohana’s cascading file system will be a tradeoff… I’m not in a huge hurry though, so I do have some time to spend if I have to learn a new framework (or new language like Ruby or Python) first. What would be the best way to invest my time? (Of course, in a perfect world, I’d just spend my time focusing on music and hire a web developer, but that would take web development away from me, which is a “hobby” that I actually enjoy…)

    My emotions and stubbornly-loyal self say to just use 3.3.1 and have some faith, but my instincts tell me that starting a project where the framework’s support will end mid-way though development (November 2013) is a terrible idea. Given the considerable investment in time I’m about to make (with both of these projects), hopefully you can understand my need to proceed with caution.

    So, what’s the future of Kohana looking like? Am I better off jumping ship now? And if so, if you used to LOVE Kohana and have since moved away to a different framework, what has your experience with said framework been like?



    (I originally posted this in the 3.3.1 release discussion, but after a whole week I didn't get any responses (not a good sign?), so I'm reposting it here as a separate discussion in hopes of getting some responses.)

  • I'm still developing with Kohana, on a daily basis. It's good, and I get my work done and am happy with the results. I'd say that the community is not huge here, and for that reason I sometimes find myself wishing I were working on Drupal projects! It's nice to have a big, vibrant collection of others' work to use and learn from... kohana-modules.com is probably the closest we have for that and it's not really the same. Then again, I guess this just arises from the fact that Kohana doesn't really "do anything", so there's no common purpose or common experience of use....

    I have recently started a couple of other projects and have decided not to use Kohana for these (one is being built with Semantic MediaWiki, for example).

  • Well i think youre just stucked into Frameworks, they question is not which Framework is the best. The question is, how can i create reusable Code for every framework or even not made for the web.

    Take a look at Zombors blog post http://zombor.github.io/ (if you love Kohana, you might know who Zombor is).

    Currently iam developing an application based on that Blog, i dont care about the Framework or the Database, i dont even care if there is a webserver, since basicly i just call php interpreter to execute my php files.

    When iam done with developing the Code, then i start to think about Framework.

    so my personal advice, spend your freetime in learning Clean Code Achitecture, someday you will have many small interactors which you could put together into new Projects by just copy and past the files.

    this video is kinda new and a bit better explained ;)

    there are also some projects written in PHP which you could use as Reference

    https://github.com/igorw/doucheswag (Silex Framework as Delivery mechanism) https://github.com/Opentribes/Core (My Project, currently not sure if i would use any framewok, maybe just a Unity 3D application as delivery mechanims)

  • @samwilson Thanks for the response – it’s great to hear that you’re still using Kohana on a daily basis. "…Kohana doesn’t really "do anything", so there’s no common purpose or common experience of use" – that’s interesting. I like that Kohana stays out of my way, but never considered that as a possible reason for such a quiet "community"…

    @BlackScorp Thanks for the response too! I started watching the video thinking I was only going to watch the first five minutes of it, but ended up watching the whole thing. Next, I read @zombor’s three blog posts that you linked to – great stuff! The huge benefits of designing an application this way (and keeping the framework at arms length) is obvious – thanks for that!

    I’m leaning towards learning Ruby and eventually using Rails as the delivery mechanism for these two projects. It’s a big investment of time though, especially given that it’s not my full-time job. Sticking with PHP would be easier, but I know easier is not always better.

    Thanks again to you both. Hopefully we’ll get some more responses…


  • > The question is, how can i create reusable Code for every framework or even not made for the web.

    The point of "frameworks" was (at least initially) that "you would be creating this crap anyway," or otherwise put "the repeatable components you create/share with all your apps." It's not that you write in a framework, it's that you wrote a framework to use, and that you added it in; even though due it's nature you're kind of inevitably forced to "add it in" right at the start, it still is for the most part "an addition to your architecture" rather then "what you're architecture is based on"; if you're using your own or one maintained by another makes no difference. Case to point, if you prototype something you might not have it in any framework but as you moved to a real thing you might have "added the framework" when you started working; similarly whenever you're thinking of your application you're likely very rarely thinking of the framework bits so technically its not there, it's something you added in when you started coding.

    Now in some cases this has become false (especially when we look at frontend frameworks) since a lot of the modern iterations on frameworks have become forced in and take the concept of providing easy functionality (views, etc) to forcing only one way of doing things (I blame rails for this), ie. "YOU wouldn't be creating this crap, BUT WE don't give you the option." Essentially things that would much better be referred to as platforms tend to call themselves or be referred to by their users also as "frameworks," because more people then not use frameworks as platforms rather then supporting code, and "perception is reality". Fortunately that's not entirely the case for all of them (backbone, reactjs).

    Personally I find the whole difference between "frameworks" and "clean code" wish washy nonsense used by clean-code evangelists to sell you their religion. Sadly the "Hey just write like this everywhere." is the same as selling an invisible pseudo-framework (of the crappy forced-in nonsense kind) to people. Good project management and informed design decisions is the solution to your "problems," there's no "one shue fits all" solution. With frameworks and things like "clean code" in general if it sounds too idealistic and is sold as a silver bullet, then it's probably just a giant carret balloon full of hot air. Nobody other then YOU is qualified to solve YOUR real world problems. It's sad how quick some people are to "judge" based on the premise that "all projects have the same real world context"; sad because it just spoils conversation and opportunities.
  • Hello,

    Maybe this can help you out a bit, we have developed Open Classifieds, using KO 3.2.2 works perfectly and we have added many many many nice stuff...like installation, admin, panel user roles, themes and many more. From that base we recently have developed open-eshop.com in less than a motnh...since we have so many things already done its' really easy and fast to develop ;)

    Take a look you wont regret. Also worth mention I am quite sure we are the biggest distributors of Kohana in the world...we have 14.000 sites form clients working with kohana :P

    I know we are not really credited for and there's barely life in the KO forum. It's just a pitty.... we have tried few times to reach more KO developers, we found bugs and was like depressing to fix a bug...so many procedures soooo slow...to fix a pull request I needed almost to cry to get it fixed...at the end seems there's not any support...really sad I love this framework and there's such an amazing work done!!!!!
  • True, true... So many bugs are just moved from one version to another.... Kohana should focus on one branch, keeping 3.3,3.2 and future 3.4 is just a waste of time and effort.
  • Bugs in 3.2 are bugs in 3.3, and bugs in 3.3 are (or will be) bugs in 3.4 too.

    As far as bugs, I think supporting multiple versions is not a bad idea. Adding features separately in different versions, (ex. feature1 in 3.2, feature2 in 3.3, but feature1 not in 3.3) is a bad idea.
  • @chema off topic: I have to mention this, please use the regular browser scroll on open-eshop.com. The scroll you have now, is horrrrrible
  • @chema just curious, did you decide to modify system files or put all changes in CFS and kohana core is fully upgradable ?
  • > Adding features separately in different versions, (ex. feature1 in 3.2, feature2 in 3.3, but feature1 not in 3.3) is a bad idea.

    It's called Semantic Versioning, and it's a terrific idea.
  • @zombor why is a terrific idea? I don't see it...
  • Read this: http://semver.org/spec/v2.0.0.html

    We don't follow these specific number guidelines, but we do follow the general concepts.
  • @zombor Exactly, so adding a feature to 3.2 would result in 3.3, essentially you're saying what I am, that 3.2 and 3.3 are not two independent versions per se.

    So everybody to understand 3.2 is supported on a bug fix level and 3.3 is currently the main version, only to this version will be added new features eventually resulting in 3.4 ...

    zombor correct me if I'm wrong.

  • Hmm if old projects break due to new features (which happens with x.x changes in Kohana, thus API changes sometimes), wouldn't that mean the first number should be incremented as described in the article posted by Zombor? Not saying it should, just checking if I understood it correctly too ;)

  • If it is to refactor the core and major classes, the connection with the old versions will be lost, it is on the one hand it will cause problems when upgrading older projects, but we must move with the times: coming soon PHP 5.6, but we still consider PHP 5.3.

  • Kohana was modern CI. Back then it was great framework, with lot of potential. Now it has old code, old patterns behind that code and I guess devs are far from "let's make K3.4 PHP 5.5 only".

    Right now Kohana is to small to keep up with 3.2, 3.3 and future 3.4 - that was good when more developers were interested in helping out. Maybye it's time to release break like it was done once before: go for 4.0 and leave the rest only for security fixes?

    Zombor has a lot of ideas, good ones. Why not focus on them? When Kohana dev team will decide that there should be a major rewrite, dropping support for PHP 5.2/3/(maybe even 4)? Time is against Kohana - codebase it's getting older, support is far away from Yii, stability of releases is worst than Fuel, future is gray, modern version (3.4? in Fuel there is v2) is somewhere in the shadows.

    Maybe it's better to go Laravel way - use some of well known libraries (ie. for database access) and focus on the core. Maybe this can be Kohana new start, a fresh breath.

    I know, most Fuel mentions get "Fule is bad, Kohana is cleaner". I know, in v1 Fuel is far from Kohana in terms of clean and separation. But it has clean path, v2 on the way, less developers is doing more, they learned their lesson and Fuel v2 might be almost the same as Kohana was to CI.

    Wake up, boo!

  • @feketegy I also said we don't follow the specific number guidelines. What you described would be the difference. I would be happier if we did follow them though.

  • @zombor Then let's follow it :)

  • Kohana version number is not crucial, it is necessary to organize support for at least PHP 5.4 as it appeared traits (mixins) and fixed serious bugs that prevent 5.3. PHP 5.5, unfortunately, not so common supported on many public hosting.

    Need roadmap from 3.4 to 4.x from a leading group of developers, assigned tasks can be solved ordinary members of the community.

    and ... 2014 has already come :)

  • The backwards incompatibility between 5.3 and 5.5 is the same as 5.3 and 5.4.

    That said, I think if somebody wants to upgrade from 5.3 (and they really should) it's better to skip 5.4 and upgrade to 5.5 directly.

  • @feketegy not all have VPS or PS, so the choice is often limited versions.

  • I wouldn't choose a hosting provider if he offers 5.2 or 5.3

  • Very good discussion. I like @Akki's perspective of the whole 'framework' lingo. @thejw23 nice point. Following closely.

    I have a feeling 2014 will see an upsurge in activities in here.

  • @thejw23 sorry late reply, I have not changed anything from the core, when I found a bug or something to improve I extended the classes. @feketegy thanks! we changed the site, that was just temporary horrrrible I know hhehe

    Not sure how can we help more from OpenClassifieds we are now a company fully dependant on this framework and we want the best for us and our customers!

  • @chema, +1 here from a company also completely invested in Kohana. :-)

  • I'm thinking a kohana weekend will pop up soon, the last one was good. @enov @zeelot

  • +1 here, completely invested in Kohana.

    Jack Ellis, let us first wait to see 3.2.3 released :)

  • Speaking of 3.4/4.0 - good idea would be to add unit testing for database. I looked at that module and it's the only one without them.

  • For me, future of Kohana should be:

    • namespaces, PSR-0/4 all the way
    • IoC in the core, and other good practices
    • separate packages. really, i18n with messages and config plus filesystem can be really easly separated and used without Kohana
    • database and auth could be dropped, there are many ready-to-use packages, just small facade/proxy to make it work with CFS configs

    base kohana version could be very similar to micro framework, with additional packages it could be extended to full stack version whenever it's needed.

    slim core, PSR-0/4, packages - this is the way PHP works today and it would be great to see Kohana go this path.

    Just my 3c :)

  • [deleted, not actual]

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion